Warren's Package Naming Proposal - Revision 1

[Michael Schwendt]

On Sat, 01 Nov 2003 12:21:59 +0100, Nils Philippsen wrote:

> On Fri, 2003-10-31 at 18:00, Michael Schwendt wrote:
> > On Fri, 31 Oct 2003 04:31:09 -1000, Warren Togami wrote:
> [...]
> > > > Are there cases where rpm would consider imap-2000a as older than 
> > > > imap-2000?
> > > > 
> > > > jbj?
> > > >
> > > 
> > > Err... you are completely right about it not being necessary in the 
> > > post-release case.  I am not sure why our fedora.us policy retained that 
> > > even though it was unnecessary for all these months.  The way I 
> > > understand the older version of rpm broken rpmvercmp behavior, this 
> > > wouldn't be a problem with those versions too.
> > 
> > * To be able to go back from 2.1.7a to a patched 2.1.7 in case the
> >   2.1.7a post-release "fix" turns out to cause side-effects.
> 
> Hmm I'm not sure if I buy that -- extrapolating form that, one should
> also be able to go back from 2.1.8 to 2.1.7 in case the new version
> turns out to cause side-effects (without any "--oldpackages" stuff or
> that point is moot).

That would be something different, since I assume 2.1.8 comes quite
some time after 2.1.7. On the contrary, 2.1.7a would be sort of a
quick brown paperbag fix attempt which would be released shortly after
2.1.7, often just a few hours later or on the same day. Including such
an upstream fix prior to publishing a package is tempting, and
sometimes it turns out right after release that the fix breaks other
parts of the software in an unexpected way and the real fix takes more
time.

I'd a fan of serial numbers, but not when they're hidden. I would
even like a scheme like

  name.serial.upstreamversion.arch.rpm

> I think the version should always be the upstream version where these
> are not incompatible with RPM version comparisons and real version
> numbers (and not CVS dates or the like because they may be substituted
> with real version numbers which are likley less RPM wise) and (optional)
> characters represent newer patch levels (and not prereleases). If that
> version number contains dashes, replacing them with underscores might be
> necessary.

Not "might be necessary", it is a strict requirement by RPM.

> > * Consistency above all.
> 
> Care to explain that one? Of course the idea I have about versioning
> seems most consistent to me but I'm sure you can shed some light on why
> version numbers differing from upstream are more consistent ;-).

Since you understand the need for a pre-release version/release
modification guideline, you do understand this guideline very well,
too, and hence it doesn't need much of an explanation IMO.

> > * The road of least surprise (with regard to upstream versioning).
> 
> That's what I want.
> 
> > * To help avoid that users think foo-1.0a would be an unstable alpha
> >   version, when in fact it is a post-release patch-level.
> 
> I do not think that is the purpose of an RPM version tag. It exists so
> the user knows that this is the upstream version number-- how else would
> a user be able to submit bug reports upstream if he cannot supply the
> real version number/string/whatever.

The user should find the software version number in the "About" or
"Help" sections, in the manual and should never rely on package
versioning. E.g. KDE 3.1.4-6 is not an upstream version, GCC 2.96
wasn't either. Now don't tell me all users know what the release
version is. Why should it be allowed (or make sense) to modify
1.0rc3-2 to 1.0-2.rc3, but not 1.0pl1-2 to 1.0-2.pl1?

> If users interpret version strings
> like "1.0a" as an alpha version when they're not -- well, that's tough
> luck but nothing that should be worked around by some RPM version
> trickeries.

It's not a primary goal, but it helps. It should not be user's
responsibility to know that Mozilla 1.5a is older than 1.5, but Foo
1.5a is a bug-fix release for Foo 1.5. The package release version
should make that obvious. Else user keeps using the unstable Mozilla
1.5a as long as rpmseek.com doesn't list a newer version.

I don't like the dependency on upstream versioning at all, cases such
as 1.01 > 1.0.2, 0.6 > 0.50, 0.010 > 0.1, 1.2 < 1.02, 1.0a < 1.0 or
1.0a > 1.0, ...  not all can be dealt with without modifying these
version numbers.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031101/b0ed886f/attachment.sig>