Core Packages in Violation of the Fedora Naming Guidelines

[Toshio Kuratomi]

For reference, here are the package naming guidelines for Fedora:
http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines

On Fri, 2006-07-14 at 16:59 -0400, Fernando Nasser wrote:
> Mind, today it is just JPackage and the Java packages, but who can tell 
> that in a few years there won't be this huge meta system with it's all 
> multi-distro package community that we (we == Fedora in this case) would 
> like to import as effortlessly as possible?  The character release 
> separator '_' would come into play again.
> 
This would be a big change in direction from how Fedora currently works
with other repositories.  We would want to define what makes another
repository an upstream source (JPackage has a framework for java
packages that we are using as well as the packages themselves.  I think
this is an important distinction.  Other repositories have frameworks
that conflict with what we are using and I think that is one of the big
differences.)

In the past, though, it has always been "mixing repos does not work."  I
think some of those arguments are still valid, even with jpackage.  Look
at the email threads I linked to in an earlier message for some of the
issues Fedora Java has already run into.

> In any case, any other separator would do, even a '.' if special-cased 
> when following a 'jpp' (or any other future upstream packaging community).
> 
> So, all that would remain would be to make the upstream JPackage release 
> practices a little bit more palatable for your tastes (note that I say 
> taste, I don't think tere are technical reasons like the one you presented).
> 
Do you think we make up Guidelines for fun? ;-)  

There are technical reasons for every guideline.

Even the consistency guideline has a technical grounding.  When you are
taking packages from people new to packaging and having people review
packages for weaknesses, more consistency makes less work and a lower
barrier to entry.

It can be carried too far when we value consistency so much that it
prevents achieving other goals but it is a goal to strive for when A)
there are no other goals B) choosing among several options that satisfy
a goal.

> I really elieve JPP folks would be agreeable on following the sae 
> standards as Fedora for instance for cvs date tags.  I forgot now, what 
> is it  0.cvsYYYYMMDD....  ?
> 
It's 0.1.YYYYMMDDcvs

Note that there is both a zero prefix and the release at the beginning
of the release.  This is important as it means I can switch from a CVS
snapshot to a named prerelease and back without difficulties:

foo-1.0-0.1.M1
foo-1.0-0.2.20060201cvs
foo-1.0-0.1.M2
foo-1.0-1

> The '0.' prefix for pre-releases is very important, as it is intended to 
> lose for the final '1'.
> 
> And the pre-release tags?  We have been obeying strictly what the 
> upstream software produced is using.  This means that if they say it is 
> 'rc2' then JPP has 0.rc2....  but if they say it is 'M4', it becomes 
> 0.M4....   Strictly what the developers called it and the software web 
> site refers to it as (normally it is also in the sorce tar ball name).
> 
> Here comes the 1st problem: uppercase characters.
> 
This is not a problem when the primary release tag comes first as in the
example above.

> 
> We have another situation that will need discussion: several upstream 
> packages are now using snapshots of dependencies before the official 
> release that are being identified only by a CVS Tag.  Not date, Tag! 
> This means underscores!!!
> 
In the Fedora Guidelines, when you make a snapshot yourself, you always
use the date.  This prevents problems if upstream switches version
control systems and loses their tags, changeset number, etc.  If
upstream is making a tarball with the tag as version then you have to
choose a version that won't conflict with upstream updates and then move
the alpha portion of the version after the Integer release.  Here's one
possible implementation:

foo-1.0.tar.gz => foo-1.0-1.src.rpm
foo-TODAYS_TAG.tar.gz => foo-1.0-2.TODAYS_TAG.fc5.src.rpm
foo-ARTS_TAG.tar.gz => foo-1.0-3.ARTS_TAG.fc5.src.rpm

This treats the snapshot as a post release according to the guidelines.
It also leaves the underscore in the package.  Some others might say the
underscore should be converted but I'd argue that "TODAYS_TAG" is a
complete entity and so the underscore is not a separator between
elements of the version.

> What I really would think should be fair in the case of upstream 
> packaging communities would be to apply the Fedora standards only after 
> the separator, i.e., to the Fedora added suffix.
> 
Unfortunately, this doesn't work.  The Fedora Naming standards exist to
protect from problems with upgrading.  The jpackage guidelines seem
mostly sane, but as you've found, things like having the primary integer
release number after the tags and dates from upstream can lead to
problems.

So to be a prefix, the upstream Naming Guidelines would have to take
care of all the cornercases that the Fedora Guidelines encompass.

Alternatively, the upstream naming could be encapsulated within the
Fedora release:
foo-1.0-4.6jpp.fc5.src.rpm
foo-1.0-5.20060707svn.1jpp.fc5.src.rpm
foo-1.0-6.rc5.1jpp.fc5.src.rpm

where "6jpp", "20060707svn.1jpp", and "rc5.1jpp" are all jpackage names.

> In any case, I believe that reasonable suggestions to improve the 
> upstream release numbering will be welcome, they must be presented at 
> that project list though:
> 
> jpackage-discuss at zarb.org
> 
First we have to know if interleaving with jpackage is a real goal for
Fedora Java.  I've written a separate email with questions about goals.

> 
> Also notice that these changes will not come overnight, as noticed in 
> this thread before.  There are releases there too, and packages for the 
> next one on August 15 are basically ready.  They are many, and it took 
> months to get to this point.
> 
This is only a problem for Fedora if we want to get more java packages
into the distro.

All new packages must meet the Fedora Guidelines.  We can amend them to
meet new situations, but we shoudn't break them.  (We've just had
problems with Mono applications because some packagers were asserting
that you absolutely had to ignore certain guidelines in order to build
Mono applications.  Turns out, that wasn't the case and now we have to
cleanup the mess.)

IF interleaving is wanted and we approve a policy that uses the jpackage
version in prefix with the stipulation that the jpackage version has to
work in all the cornercases identified, then there may be some jpackages
that have to munge the version in order to work.

For instance:
axion-1.0-0.M3.1jpp.src.rpm
would have to be changed to axion-1.0-0.1.M3.3.fc5.src.rpm

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20060714/35522c98/attachment.sig>