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(a)czarc.net>
>To: fedora-test-list(a)redhat.com
>Cc: fedora-devel-list(a)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 -