public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-apps@cygwin.com
Subject: Re: per-version hints proposal
Date: Tue, 21 Jun 2016 12:03:00 -0000	[thread overview]
Message-ID: <20160621120321.GL3667@calimero.vinschen.de> (raw)
In-Reply-To: <8b4723b2-1bd5-3604-1deb-cfd0a1c7b9d9@dronecode.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]

On Jun 20 16:28, Jon Turney wrote:
> 
> Currently, the setup.hint file is shared between all versions.
> 
> This means that manual intervention (by the package maintainer, or on
> sourceware) is needed when versions have different dependencies.
> 
> To automate this problem out of existence, I suggest replacing the
> setup.hint file in an upload with a package-version-release.hint file.
> 
> This will be basically identical to the existing setup.hint, with the
> advantage that it can't be trampled on by a future version, with the
> following changes:
> 
> * 'skip' doesn't seem meaningful on a per-version basis.  Since it seems we
> can automatically detect packages which should have this applied anyhow (see
> the discussion in [1]), I'd suggest ignoring this hint, to be retired at
> some future date.
> 
> * 'curr', 'prev' and 'test' don't make sense on a per-version basis.  So I
> suggest a separate file for these version overrides (versions.hint?)

Ideally we wouldn't need something like "prev" at all since the version
number itself is sufficient to specify what's curr and what's old.

As for test, IMHO it would make sense to specify "this is a test
release" right in the cygport file.  This in turn could create a
per-version hint with a test marker which is evaluated by calm
accordingly.  For instance, the name of the file could take over this
role.  Or even better, the package version number itself.

This would have an additional benefit:  We couldn't just move a package
from test to curr, it would have to be explicitely rebuilt as non-test
release.

I think this is the cleanest solution.

> cygport will be updated to create a pvr.hint rather than setup.hint
> 
> 
> calm will be changed so that:
> 
> * The requires: line written in setup.ini will contain the union of the
> requires: from each pvr.hint
> 
> * The sdesc:, ldesc:, category: and message: lines in setup.ini will be
> taken from the pvr.hint for the curr version
> 
> * While it's already effectively mandatory that a package has a curr
> version, this requirement will be documented and enforced.
> 
> * The source: line in setup.ini for a package version will consider any
> external-source: from the corresponding pvr.hint
> 
> * Uploads with a setup.hint will continue to work as before, for a
> transitional period.
> 
> 
> No setup changes are required.
> 
> 
> Immediately, this avoids the need for manual intervention when versions have
> different dependencies, and going forward, this is lays some groundwork for
> supporting per-version dependencies.

Sounds good to me.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-06-21 12:03 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-20 15:28 Jon Turney
2016-06-21 12:03 ` Corinna Vinschen [this message]
2016-06-21 13:49   ` Marco Atzeri
2016-06-21 14:28     ` Corinna Vinschen
2016-06-21 15:32       ` Marco Atzeri
2016-06-21 14:09   ` Eric Blake
2016-06-21 14:27     ` Corinna Vinschen
2016-06-21 18:04     ` Achim Gratz
2016-06-21 18:27   ` Jon Turney
2016-08-30 12:24 ` Jon Turney
2016-08-31 19:14   ` Achim Gratz
2016-09-01 17:15     ` Jon Turney
2016-12-08 19:30   ` Jon Turney
2016-12-09 10:46     ` Corinna Vinschen
2016-12-09 11:10       ` Corinna Vinschen
2016-12-12 13:29         ` Jon Turney
2016-12-12 13:29       ` Jon Turney
2017-04-08 17:00     ` Achim Gratz
2017-04-12 20:51       ` Ken Brown
2017-04-13  6:24         ` Achim Gratz
2016-09-17  6:15 ` Achim Gratz
2016-09-18  5:17   ` Marco Atzeri
2016-09-18 15:14     ` Jon Turney
2016-09-18 16:12       ` Achim Gratz
2016-09-18 16:29         ` Achim Gratz
2016-09-19 15:37           ` Ken Brown
2016-09-19 18:24             ` Achim Gratz
2016-09-19 22:23               ` Jon Turney
2016-09-18 16:40       ` Ken Brown
2016-09-18 16:53         ` Marco Atzeri
2016-09-18 17:16           ` Achim Gratz
2016-09-18 18:08             ` Marco Atzeri
2016-09-22 13:44 ` Eric Blake
2016-12-10 22:42 ` How to override previous version? David Rothenberger
2016-12-11  0:03   ` Jon Turney

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=20160621120321.GL3667@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-apps@cygwin.com \
    /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).