This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: upset, genini: different version ordering
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 20 Oct 2015 14:33:38 +0100
- Subject: Re: upset, genini: different version ordering
- Authentication-results: sourceware.org; auth=none
- References: <87380i671e dot fsf at Rainer dot invalid> <55AD399D dot 7020001 at dronecode dot org dot uk> <5617C006 dot 7070908 at dronecode dot org dot uk> <20151019154236 dot GC18989 at calimero dot vinschen dot de> <87mvvehj3t dot fsf at Rainer dot invalid> <1445275721 dot 10544 dot 14 dot camel at cygwin dot com> <87a8rehgkg dot fsf at Rainer dot invalid> <20151020102722 dot GH5319 at calimero dot vinschen dot de>
On 20/10/2015 11:27, Corinna Vinschen wrote:
On Oct 19 20:13, Achim Gratz wrote:
Yaakov Selkowitz writes:
Switchable versioning schemes means that code has to be multiplied in
both setup and upset, which is just asking for problems. There needs to
be one single versioning scheme, period, and using RPM's makes sense.
You do know that RPM specifically has an emergency exit in the form of
"serials", do you?
I don't. Brief description?
This is a reference to the RPM "Serial:" tag
This seems to be pretty obscure, but [1] says "Like the Epoch:, the
Serial: directive should be a number that counts upward. Modern packages
should use the Epoch: directive instead of Serial:, since Serial: has
been deprecated for many, many rpm versions. "
What about epoch handling as Yaakov
suggested, does that help? Jon, as our local upset guru, how tricky
would it be to add epoches to upset?
Or, in other words, how complicated would it be to have the same
RPM version handling in setup and upset both?
I've done the first step, which is to change upset to use the same
ordering as setup (which uses an RPM-like ordering)
Patch not attached due to upset license uncertainties, but you can find
it at
/sourceware1/cygwin-staging/setup/0001-upset-Change-version-sorting.patch on
sourceware.
[2] is the list of packages whose ordering would change if this was
used. On further study, it appears that upset is ordering all of these
but tcl-itcl in the opposite order to the chronological (and presumably
intended) order.
Adding epoch parsing would be additional work. I'm not sure how much
value that would have since (a) we are effectively limited to 2 package
versions, and (b) we can force a given ordering using setup.hint
[1]
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/
[2] https://cygwin.com/ml/cygwin-apps/2015-10/msg00003.html