This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: upset, genini: different version ordering
- From: Yaakov Selkowitz <yselkowitz at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 20 Oct 2015 12:03:28 -0500
- 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> <562642B2 dot 5030607 at dronecode dot org dot uk> <20151020155048 dot GI5319 at calimero dot vinschen dot de>
On Tue, 2015-10-20 at 17:50 +0200, Corinna Vinschen wrote:
> > 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
>
> Yaakov thinks we need epoch. Yaakov, could you briefly outline why we
> should need it? Do we have real-world examples in the distro where we
> could need it? I guess Achim's perl packages are particulary nice
> examples?
First, let's remember that this isn't just about upset getting prev: and
curr: right, but also about setup knowing when to upgrade by default.
Therefore, simply tweaking setup.hint files is insufficient.
Besides sorting out our current discrepancies, here is a perfect example
of a use for epoch:
https://cygwin.com/ml/cygwin-announce/2015-07/msg00015.html
https://cygwin.com/ml/cygwin-announce/2015-07/msg00050.html
In short, xdelta was updated from 1.x to 3.x, then it was realized that
both were needed, and so xdelta was reverted to 1.x and xdelta3 was
created. Instead of saying "oh btw you need to revert xdelta to 1.x
yourself" (which is all we could do currently), the solution would be to
bump epoch on xdelta-1.x, which would force it to be considered newer
than the short-lived xdelta-3.x by both upset and setup.
As for implementation, the idea would be to use a special character in
the version number of tarballs as so (pseudocode):
char epoch[N] = {}, *sep;
if ((sep = strchr(version, SEPARATOR))) {
strncpy(epoch, version, sep - version);
version = sep + 1;
} else
epoch[0] = "0";
Then compare epochs first, then version and release to determine which
is newer. As for the separator, in RPM it is ':' but as we will need to
have this character in the tarball name and Windows doesn't allow that
in filenames, we will need to pick something else.
On the cygport side, this would be triggered by defining EPOCH in
the .cygport file, *not* by using this character in VERSION.
--
Yaakov