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 14:28:00 -0000	[thread overview]
Message-ID: <20160621142839.GC12441@calimero.vinschen.de> (raw)
In-Reply-To: <2bfdb839-05a8-4d07-7ae1-a8794615a5bc@gmail.com>

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

On Jun 21 15:49, Marco Atzeri wrote:
> 
> On 21/06/2016 14:03, Corinna Vinschen wrote:
> > 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:
> > > 
> 
> fine for me.
> 
> 
> > 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.
> 
> not a huge fan of this.
> The last time we made the perl transition we put a lot of package in
> test as temporary solution. Rebuild all just to change a label
> seems a waste of time.

Not a huge fan of what part?  I think in general it makes sense to
keep the "test" info in the ${version}.hint file.  If a simple
change to this file moves ${version} to non-test, ok with 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 14:28 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
2016-06-21 13:49   ` Marco Atzeri
2016-06-21 14:28     ` Corinna Vinschen [this message]
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=20160621142839.GC12441@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).