Core Packages in Violation of the Fedora Naming Guidelines

Tue Jul 11 23:56:10 UTC 2006

On Tue, 2006-07-11 at 18:33 -0400, Elena Zannoni wrote:
> I suspect RHN will get very confused if these changes are not made
> correctly.  Can you please address each of the categories with the
> correct way to do the naming? I.e, what does incorrect distro tag
> mean, and what would be the right way to do it.  BTW I doubt that we
> can fix these for FC6t2. (speaking for the tools ones) What's the
> impact of fixing this stuff later?

Tossing this back on the list, as I know others will have the same
questions.

Some of these items might need epoch changes. I'll describe the
specifics:

>  > Uses incorrect dist tag
>  > ========================
>  > anacron-2.3-38.FC6.src.rpm

The "all caps" hardcoded dist tag is wrong. Instead, you should use
%{?dist} to let the buildsystem (both plague and brew support this)
determine what the distribution tag is. It will fill in %{dist}
with .fc6, for example. The dist tag bits are documented here:
http://fedoraproject.org/wiki/DistTag

Hardcoding the value for the dist tag is no longer allowed, since the
buildsystem can do it for you.

So, for example:
>  > gdb-6.3.0.0-1.132.FC6.src.rpm

With the proper dist tag usage, this package becomes:

gdb-6.3.0.0-1.132.fc6.src.rpm

Inside the spec, you'd see:

Release: 1.132%{?dist}

rpm thinks that fc6 > FC6, so there should be no update issues in
remedying this.

>  > Uses invalid release (Release value starts at 1, not 0)
>  > =======================================================

This one should be pretty straightforward. Don't use Release: 0. Start
at 1.

>  > cairo-java-1.0.4-0.src.rpm

To fix this package, all you need to do is bump the release number to 1.

cairo-java-1.0.4-1.src.rpm

>  > Invalid non-numeric characters in release
>  > ==========================================

The Fedora rules are pretty straightforward about non-numeric characters
in the Release field. Unless it is a pre-release package (alpha/beta) or
a snapshot release (cvs/svn), then you cannot put non-numeric characters
into the release field.

To fix these packages, the most obvious way is to strip out all the junk
that is in the Release field after the initial number, then increment
that number.

The only exception to this rule is for the dist tag, and you have to use
%{?dist} in the release field as documented. (after the integer, with
nothing else after it).

I highly encourage that you use integers in the Release field, and not
whole numbers (e.g. use 3, not 3.206), because that is the best way to
confuse rpm (rpm thinks 3.206 is newer than 3.21). We're not going to
run out of integers anytime soon.

Also, unless you're following the snapshot rules, don't put dates in the
Release field.

The full set of rules, with examples, are here:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease

So, some examples:

>  > adaptx-0.9.6-1jpp_3fc.1.src.rpm

Fixed: adaptx-0.9.6-2.src.rpm
Fixed (with dist tag): adaptx-0.9.6-2.fc6.src.rpm

>  > xorg-x11-xkbdata-1.0.1-8.xkbc0.8.0.src.rpm

Fixed: xorg-x11-xkbdata-1.0.1-9.src.rpm
Fixed (with dist tag): xorg-x11-xkbdata-1.0.1-9.fc6.src.rpm

>  > Bad CVS naming (cvs should be at end of date, not beginning)
>  > ============================================================

CVS falls under the snapshot rules. To handle snapshots, first identify,
is this a pre-release, or a post-release?

> > krb5-auth-dialog-0.6.cvs20060212-3.src.rpm

I'll assume this is a pre-release, and that 0.6 has yet to be released.
In this case, this package should be fixed as:

Fixed: krb5-auth-dialog-0.6-0.7.20060212cvs.src.rpm
Fixed (with dist tag): krb5-auth-dialog-0.6-0.7.20060212cvs.fc6.src.rpm

If you need to patch a pre-release or put in a new cvs checkout, you
bump the non-zero integer in the Release field, but LEAVE THE ZERO AS
ZERO. This is important.

Unfortunately, this is a case where conforming to the guidelines will
require a one-time epoch bump in the new package, since rpm thinks that
0.6.cvs20060212-3 is newer than 0.6.

Now, when 0.6 actually releases, you release a new package like:

Fixed: krb5-auth-dialog-0.6-1.src.rpm
Fixed (with dist tag): krb5-auth-dialog-0.6-1.fc6.src.rpm

>  > NetworkManager-0.7.0-0.cvs20060529.1.src.rpm

I'll assume this is a post-release snapshot. Something that has come out
after 0.7.0, but I don't know if the next release will be 0.7.1 or not.

At some point in time, there was a: NetworkManager-0.7.0-1.src.rpm

The post release package would then look like:

Fixed: NetworkManager-0.7.0-2.20060529cvs.src.rpm
Fixed (with dist tag): NetworkManager-0.7.0-2.20060529cvs.fc6.src.rpm

Now, with post release packages, you should make sure that you keep
incrementing that first integer field as you make changes. So, if you
make a newer cvs checkout, say 20060611, then you'd get:

Fixed: NetworkManager-0.7.0-3.20060611cvs.src.rpm
Fixed (with dist tag): NetworkManager-0.7.0-3.20060611cvs.fc6.src.rpm

Only when you increment the Version field, should you reset the Release
back to 1. (or fail to increment it) Example:

Fixed: NetworkManager-0.7.1-1.src.rpm
Fixed (with dist tag): NetworkManager-0.7.1-1.fc6.src.rpm

>  > Bad alpha naming (should be e.g. foo-1.8.1-0.1.alpha9)
>  > =======================================================

Alphas are pre-releases. Even if something has been in alpha for eons.

>  > cdparanoia-alpha9.8-27.1.src.rpm

Fixed, this becomes:

Fixed: cdparanoia-9.8-0.28.alpha.src.rpm
Fixed (with dist tag): cdparanoia-9.8-0.28.alpha.fc6.src.rpm

Doesn't require an epoch bump.

>  > libtheora-1.0alpha5-1.2.1.src.rpm

Fixed: libtheora-1.0-0.2.alpha5.src.rpm
Fixed (with dist tag): libtheora-1.0-0.2.alpha5.fc6.src.rpm

Requires a one-time epoch bump.

>  > perl-XML-Grove-0.46alpha-29.1.src.rpm

Fixed: perl-XML-Grove-0.46-0.30.alpha.src.rpm
Fixed (with dist tag): perl-XML-Grove-0.46-0.30.alpha.fc6.src.rpm

Requires a one-time epoch bump.

>  > Bad beta naming (should be e.g. foo-1.8.1-0.1.beta5)
>  > =====================================================

Same logic and naming scheme as alpha.

>  > aqbanking-1.8.1beta-5.src.rpm

Fixed: aqbanking-1.8.1-0.6.beta.src.rpm
Fixed (with dist tag): aqbanking-1.8.1-0.6.beta.fc6.src.rpm

Requires a one-time epoch bump.

>  > autofs-5.0.0_beta6-5.src.rpm

Fixed: autofs-5.0.0-0.6.beta6.src.rpm
Fixed (with dist tag): autofs-5.0.0-0.6.beta6.fc6.src.rpm

Requires a one-time epoch bump.

>  > Invalid use of underscore
>  > ==========================

Underscores are not valid delimiters for any field, unless they are in
the name. This is documented here:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#NormalPackages

>  > adaptx-0.9.6-1jpp_3fc.1.src.rpm

This package also has all sorts of non-numeric addon fun. We fixed him
above, but just to reillustrate:

Fixed: adaptx-0.9.6-2.src.rpm
Fixed (with dist tag): adaptx-0.9.6-2.fc6.src.rpm

>  > eclipse-changelog-2.1.0_fc-1.src.rpm

This guy looks like he just needs a proper dist tag:

Fixed (with dist tag): eclipse-changelog-2.1.0-2.fc6.src.rpm

It also needs a one-time epoch bump, since rpm thinks that 2.1.0_fc >
2.1.0.

Why are we making everyone follow these rules? So that we avoid pain,
confusion, and having to make rpm cry. (Everytime I think about RPM now,
I think about Meatwad from Aqua Teen Hunger Force)

These rules ensure clean, predictable upgrades, and the ability to look
at a package and easily determine key information about it. Is it a
pre-release? Did it come from a CVS checkout?

All of the Naming Guidelines are here:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines

If you're not sure if you need to bump the epoch when you make the
change, use fedora-rpmvercmp. It's in the fedora-rpmdevtools package,
and it will let you compare a Epoch:Version-Release to another
Epoch:Version-Release, and tell you what rpm thinks is greater.

~spot
-- 
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!