version/release identification for packages

[Mike A. Harris]

On Tue, 2 Mar 2004, Gene C. wrote:

>Date: Tue, 2 Mar 2004 14:52:47 -0500
>From: Gene C. <czar at czarc.net>
>To: fedora-test-list at redhat.com
>Cc: fedora-devel-list at redhat.com
>Content-Type: text/plain;
>  charset="us-ascii"
>List-Id: Development discussions related to Fedora Core
>    <fedora-devel-list.redhat.com>
>Subject: version/release identification for packages
>
>There seems to be this desire to put oddball version/release identifiers for 
>packages.  First, in FC2-T1 there was util-linux 2.12pre-3 being updated with 
>2.12-4 but rpm and up2date consider the older package to be newer.  Now, for 
>FC1 the recent update for tcpdump has 3.7.2-7.1 being updated by 
>3/7/2-7.fc1.1 but (again) the older packages is considered newer (and the 
>same is true for libpcap 0.7.2-7.1 being updated by 0.7.2-7.fc1.1).
>
>For folks just letting up2date figure out what needs to be updated, this is a 
>major problem.  Please stop doing this.

Not everyone updating packages is aware that 2.12-4 will be 
considered older than 2.12pre3, and so that is how problems like 
this get into the tree.  If a particular engineer has never 
encountered this problem before, they'll not be aware of it until 
the problem has actually surfaced.

The way I handle such a version bump is to do:

Version: 2.12
Release: whatever

then the pre3 one would become:

Version: 2.12
Release: 0.pre3.whatever

When version 2.13 is released, it will upgrade cleanly.

The only 2 ways I can think of to avoid this type of problem
completely is to have an established and defined policy which
everyone is to follow to the letter to avoid these types of
problems, and not make it a "developer preference" type of thing.
Then with a defined policy, there would be 2 ways of enforcing 
it:

1) Automated packaging tests which are ran prior to a package 
being built in the buildsystem, and fail the package 
automatically if any common problem is detected of the nature of 
the above.  Not all scenarios are detectable most likely and so a 
list would have to be kept and updated over time I believe in 
order to be more useful.

or

2) Mandatory peer review of each package update, with one or more
people having to sign off that a package update meets the 
established packaging policies.


Those are the two mechanisms I can think of.  IMHO, only #1 is 
really something that could be realistically considered, as #2 
would make package updates asynchronous and add an extra layer of 
delay to the already complicated process.

Any other ideas?


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat