version/release identification for packages

[Panu Matilainen]

On Wed, 2004-03-03 at 05:47, Mike A. Harris wrote:
> 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.

Hey, we already have such a policy, it's just a matter of 
a) reading it b) confirming (at least trying) to it:
http://www.fedora.us/wiki/PackageNamingGuidelines
That doesn't fit right in as internal RH policy because it was
specifically written as an external policy, trying to cope with various
things that simply don't exist for you internally. But it's a start... 
and does cover for example this specific case.

> 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.

2) is what fedora.us currently uses and yes, it isn't workable for RH
internally I think. Automating that would be an extremely nice thing,
but probably non-trivial task.

	- Panu -