Re: Reminder: impending GNOME 1.4 RC1 deadline

[Ian Peters <itp ximian com>]

On Sat, Mar 10, 2001 at 04:17:52PM -0500, Owen Taylor wrote:
> 
> > That said, it makes things difficult for people building binary packages
> > if the version string contains anything other than dot-separated digits.
> > 1.2.9pre1, for example, is thought to be newer than 1.2.9 by every
> > packaging system I've ever seen. This requires a packager to introduce a
> > package epoch when the final version comes out, munge the version string
> > into something the package system would think is older, or ignore the
> > prerelease completely.
> 
> To repeat, once, once, again.
> 
> Yes, package maintainers probably shouldn't call there packages
> 1.2.9pre1, but if they do, then packagers have to realize
> that the right solution is NOT to introduce an epoch, but
> for the packager to deal with the problem when creating
> the package, by either versioning the package:
> 
>  1.2.8.91-1
> 
> Or by encoding the "pre" status into the release
> 
>  1.2.8-0.1
> 
> (My preferred solution). There is no reason whatsoever that the 
> name of the tarball needs to be embedded in the package name,
> and an Epoch is very much a too heavy-weight solution to this
> problem.

Let's face it, epochs are a hack of a solution within RPM (discover
this by examining either the lack of pervasiveness of epoch support in
rpmlib, or the fact the the "epoch" field is actually a perversion of
the older RPMTAG_SERIAL functionality).  Lacking a centralized package
repository like there is with Debian, epochs in RPM packages
predominately leads to user confusion and frustration.

This isn't to say they aren't necessary, just that they suck.

That said, both of your solutions suck.  One of them requires the
packager to pervert the version field, which is supposed to represent
the upstream package version, and the other forces their hand when
dealing with the revision (release) field, which is supposed to
represent the iteration of the package generated from a given tarball.

Honestly, how hard is it for the maintainer to give an appropriate
version string, such as 1.x.90 leading up to 1.(x+1).0, instead of
forcing the packager to introduce hacks like this?

> [ Who's going to be very upset if he finds out that the Ximian
>   folks increased the epoch on their packages for GTK+-1.2.9
>   after being explicitely told what they needed to do. ]

No, we didn't.

That said, it wouldn't have been that inappropriate.  The epoch is
used for situations where it's desirable to "force" (strongly
recommend) that a user back down versions, or where the upstream
version scheme changes.  In this circumstance, by switching from an
X.Y.Z scheme to X.Y.ZpreW, you've essentially done that.

It's not your job to explicitly tell packagers what to do.

-- 
Ian Peters      "...it is 5 am and the sun has charred the other
itp gnu org      side of the earth and come back to us and painted
itp ximian com   the smoke over our heads an imperial violet..."