From: Jon Turney <jon.turney@dronecode.org.uk>
To: "cygwin-apps@cygwin.com" <cygwin-apps@cygwin.com>,
"Schulman, Andrew" <schulman.andrew@epa.gov>
Subject: Re: replacing a previous package verson
Date: Mon, 11 Apr 2022 14:49:51 +0100 [thread overview]
Message-ID: <9a47b168-d3c1-ab9a-6bd2-6c4b9eef00ea@dronecode.org.uk> (raw)
In-Reply-To: <pc885hl718f8rnschivp3e5p82nltn80f8@4ax.com>
On 11/04/2022 14:02, Andrew Schulman via Cygwin-apps wrote:
> After all this time I feel that I should know the answer to this, but here
> goes.
>
> I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1,
> leaving fish-3.3.1-1 as the previous release.
>
> What's the best way to do this? Should I create override.hint, with
> keep: 3.3.1-1
This alone means 'keep 3.3.1-1 as well as anything else you would keep'.
Since that seems to be what you really want ('keep previous major
version around '), I'd suggest just doing that.
If you really feel the presence of 3.4.0-1 is unhelpful and want to
remove it, you can use the 'deleting' instructions at [1] to remove 3.4.0-1.
You can create the dash-prefixed files in cygport's staging directory
(${PN}-${PVR}.${ARCH}/dist/) before a 'cygport upload', if you want to
make both changes at once.
Since that mechanism is not terribly easy to use, it's also ok to ask
here for someone with shell access to remove the files for you. (The
script which does this is named 'vault', so this is sometimes referred
to as 'vaulting').
But I'd suggest just focusing on specifying what you want to keep, and
allow calm to manage cleaning up stuff that's surplus to requirements
for you.
[1] https://cygwin.com/package-upload.html#deleting
> replace-versions: 3.4.0-1
This isn't what you want.
'replace-versions' is an instruction to setup, that those versions
should always be replaced, even by non-superseding (lower) versions.
This is to intended to handle the case when a broken package is
released, and we want to withdraw that package without releasing a later
version, and downgrade it anywhere it's installed.
That's the idea the final paragraph after [2] is meant to communicate.
[2] https://cygwin.com/packaging-hint-files.html#override.hint
> ? This seems as though it might be right, but one question I have is, will
> override.hint persist in future releases unless I replace it?
Yes, override.hint persists until changed or removed (but note that it's
contents don't currently apply recursively).
next prev parent reply other threads:[~2022-04-11 13:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 13:02 Andrew Schulman
2022-04-11 13:45 ` Andrew Schulman
2022-04-11 14:33 ` Jon Turney
2022-04-11 13:49 ` Jon Turney [this message]
2022-04-11 15:34 ` Andrew Schulman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a47b168-d3c1-ab9a-6bd2-6c4b9eef00ea@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=cygwin-apps@cygwin.com \
--cc=schulman.andrew@epa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).