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@xxxxxxxx > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
