public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
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).

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