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).
