Core Packages in Violation of the Fedora Naming Guidelines

[Fernando Nasser]

Hi Jesse,

Jesse Keating wrote:
> On Wednesday 12 July 2006 16:58, Fernando Nasser wrote:
>> And for what?  What are the technical advantages that will be obtained
>> with this change?  If we knew what effect wants to be obtained we could
>> perhaps think together in a better way to solve it.
> 
> Right now it is difficult to respin a release on say FC5 w/out running into 
> having it be versioned HIGHER than that in FC6 or in devel.  If we're going 
> to adopt the jpackage naming scheme into our guidelines there needs to be 
> some thought put around this.
> 

Of course.

> We recently approved the ability to add an int after the dist tag for this 
> purpose, so that the release could be:
> 
> <int>%{?dist}.<int>  or once translated:
> 
> 3.fc6.1
> 

Sounds good to me.

> This keeps it lower than say 3.fc7 but allows for it to be respun w/out having 
> to bump the fc7 version.
> 

Nice idea.  So far so good.

> How can this fit into the jpp naming scheme as it stands?  Currently there is 
> just 'fc', no indication which Fedora release, and there are no numbers after 
> it.  This should be addressed.
> 

I wish so much this would be the only problem that people would be 
seeing.  Because any, absolutely any, suffix scheme to whatever the JPP 
release is would work fine for JPackage as well.

MMMMMM-N.N.N-NNNNjpp<suffix>

where suffix could perfectly be <int>%{?dist}.<int>

We need a separator though.

I think it could be proposed a second use for underscores in addition to 
package with underscores on well known upstream names.

Underscores could also be used to clearly separate releases when the 
packaging is imported from upstream.

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.

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

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

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.


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

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.

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


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.

Also, there are upgrade considerations wit regards to previous JPP 
releases and many other things that would need to be exhaustively 
tested.  It is a project that exists since before Fedora was even born: 
it had releases for RHL 8 or before if I am not mistaken.
Note that is not only Fedora that imports the RPMs from JPackages.
Other distributions and Java SDK providers also use it and may want to 
have a say as well.

In summary Jesse, we have no attachment to the _Nfc bit in particular. 
Any suffix will do, whatever works better for Fedora.  Changes in the 
upstream release string is what causes interoperability problems.


Thanks a lot for posting a specific technical issue.  It works so much 
better that way.


Best regards,
Fernando