public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@Nexgo.DE>
To: cygwin-apps@cygwin.com
Subject: Re: [[PATCH setup] 0/3] Prepare for colons in version numbers
Date: Tue, 31 Oct 2017 10:06:00 -0000	[thread overview]
Message-ID: <ot9hub$3if$1@blaine.gmane.org> (raw)
In-Reply-To: <4eb3bda2-c6a2-bc48-d042-d54229a28514@dronecode.org.uk>

Am 30.10.2017 um 16:58 schrieb Jon Turney:
> "everyone" != "everyone, ignoring people who disagree with me"

I think this is an unfair summary of my position.

> If you think epochs are a bad idea, you need to give reasons, not just 
> pretend there is no debate.

I was strictly talking about those folks who've had the opportunity in 
practise so far, which is all the major GNU/Linux distributions.  The 
ones I'm aware of aren't using epochs and instead decided to use other 
means of achieving the same (or similar) goals.  In fact they created 
rules to not use epochs even though the tools support them.  Their line 
of reasoning always was (and still is), that once you start using epochs 
there is no way going back and you could just as well have used 
monotonic release numbers instead of versions.  The other point is that 
it is close to impossible that everybody will agree on what the epoch 
ought to be.  The last point is that once an epoch bump is introduced, 
you can't decide to sort things differently unless you're prepared to 
invalidate all existing released packages.

So, we might have that debate now for Cygwin because we might finally 
use a library that supports epochs, but others have been there before us 
and concluded that epochs aren't worth the trouble.  I don't see our 
situation with Cygwin different enough to come to a different conclusion 
than the distro folks and they've had many more brains to pick on this 
issue.

> I agree it does not work well for CPAN-style floating point version 
> numbers, but that's your problem to solve, or not, however you like...

You can stop using this particular example if it helps you not taking a 
right at Albuquerque each time version numbers come up.  This is just 
one of many examples where two sets of sane versioning rules don't 
produce the same ordering.

There are plenty of other examples where versioning upstream for 
whatever reason doesn't conform to whatever set of rules to make them 
sortable and it's not all that unheard of that upstream decides to 
change their rules once in a while even if they otherwise keep their stride.

So whatever the reason, you will have to impose a sort order whenever 
there is a package that doesn't follow the rules builtin to setup and 
hence sorts incorrectly.  You say epochs are _the_ way to do that and 
I'm pointing out that the distro folks have come to the conclusion that 
it isn't and are using different mechanisms.

-- 
Achim.

(on the road :-)

  reply	other threads:[~2017-10-31 10:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27 18:47 Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 1/3] Remove the function filemanip.cc:base Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 2/3] Bump the installed.db version to 4 Ken Brown
2017-10-27 18:47 ` [[PATCH setup] 3/3] Remove the ScanFindVisitor class Ken Brown
2017-10-27 19:27 ` [[PATCH setup] 0/3] Prepare for colons in version numbers Achim Gratz
2017-10-27 19:33   ` Ken Brown
2017-10-27 19:48   ` Brian Inglis
2017-10-27 20:31   ` Yaakov Selkowitz
2017-10-30 15:58   ` Jon Turney
2017-10-31 10:06     ` Achim Gratz [this message]
2017-10-31 11:21       ` Corinna Vinschen
2017-10-31 16:22         ` Brian Inglis
2017-10-31 18:16         ` Achim Gratz
2017-10-31 18:32           ` Brian Inglis
2017-10-30 15:55 ` 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='ot9hub$3if$1@blaine.gmane.org' \
    --to=stromeko@nexgo.de \
    --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).