[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Core Packages in Violation of the Fedora Naming Guidelines

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:


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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]