Core Packages in Violation of the Fedora Naming Guidelines

[Nicolas Mailhot]

Le jeudi 13 juillet 2006 à 14:56 -0700, David Lutterkort a écrit :
> On Thu, 2006-07-13 at 08:43 +0200, Nicolas Mailhot wrote:
> > Le mercredi 12 juillet 2006 à 18:52 -0700, Toshio Kuratomi a écrit :
> > 
> > > So it looks like the idea of "upgrading" from a Fedora package to
> > > JPackage to Fedora that was expressed by Fernando Nasser [1]_ is an
> > > anti-goal (ie: It is explicitly not the desired behaviour.)
> > 
> > The migration is more jpp -> fc but even if fc -> jpp should never be
> > desirable ideally the truth is fc sometimes lags behind and users would
> > rather use the latest jpp package than the old fc-customized one.
> > 
> > It's not a simple problem-space. 
> 
> That's why it would be very helpful if somebody who is familiar with
> that problem space could write up what the packaging guideline should
> be, and why it should be that way.

I don't follow JPackage these days and didn't propose the original
interleaving spec. So all I'll write there is based is based on my
personal understanding, which may not be current.

The current convention aims to make full interleaving possible. A
JPP-like stacked release flow looks like this :

1. java project releases a code dump
2. someone @jpp does the initial sanity checking and rpm packaging.
People from various distributions (Fedora, Suse...) follow the process
and review the result (the @jpp someone may be a @rh or @suse someone
too)
3. the fedora java team cherry-picks the packages it deems the most
interesting, and releases tweaked versions in fc/rhel (aot compiling,
killing of all the deps which do not have a viable FLOSS version yet,
etc)

Rince and repeat for every release of a java app.

This is a continuous FE-like rolling release process.

Now even if it would be much easier on everyone involved if only rolling
releases happened, sometimes core java packages (jvm, ant, tomcat...)
have a major version change, and require a full repository rebuild (as
in every package/spec needs to be audited to check it will work with the
new core). A FC-like release process then takes place, with a devel
branch populated like Rawhide, and tested till it's ready to be declared
the new jpp release. Needless to say core JPP packaging policy changes
only happen during this sort of full-repo release.

The naming guidelines must allow transparent transition from 2 to 3 : ie
supposing you have a system with a set of jpp packages installed, allow
update of all or part of them to their fedora-enhanced forks.

ie if JPP released foo-2.3-1jpp allow yum update to foo-2.3-something,
where something tells yum its 1jpp plus some enhancements

However should JPP release foo-2.3-2jpp with some important fixes in the
packaging, and @rh people can't repackage it on a timely manner because
they're swamped by a RHEL release, upgrade from foo-2.3-something to
foo-2.3-2jpp is also desirable. Of course that paves the way to
foo-2.3-2jpp to foo-2.3-somethingelse upgrades once fc did its forking.

So you have a 
foo-2.3-1jpp -> foo-2.3-something -> foo-2.3-2jpp -> foo-2.3-somethingelse
pattern. Needless to say Fedora has no control over the release tags jpp
uses 

(However it's certainly possible to propose JPP a new streamlined
release naming convention for its packages, but it will only take effect
when every JPP package is rebuild, and probably not fully till the next
JPP release. Impatient people can always join the JPP packaging team to
make things happen faster)

The jpp -> fc transitions are explicitely encouraged by the rh java
team.

The fc -> jpp transitions should not happen in ideal life, but are a
necessary evil. They are needed for when the fc repackaging lags, or
when users need package versions in the JPP devel branch (needless to
say FC only forks stable JPP repository states, not devel). The advice
to users is to inhibit them either by not enabling the jpp repo or by
adding specific excludes for the stuff they don't want upgraded by jpp.
But should the user decide to enable them, they must work in yum too.

You must realise the worst case for the time a java app takes to hit FC
is :

1. java project releases a code dump
2. someone @jpp does the initial packaging. However app needs a new
major version of a core java component, so it's released in the JPP
devel branch
3. ... wait some months till the devel branch graduates to stable JPP
4. ... wait some weeks till the fedora java team does the fc
repackaging. Result hits rawhide
5. ... wait some months till rawhide graduates to stable FC
6. ... wait some months/years till stable FC is forked in RHEL

the fc->jpp update path is designed to allow users who can't wait for 6.
or 5. use 2. or 3.

Also the length of 1 -> 2 and 2 -> 3 is pretty much only dependant on
the manpower JPP got at the time, it can go faster or slower depending
on the packaging time individual people donate.

This process is much slower than what happens in FE, because java
includes glibc-like core packages, not only packages with little or no
dependency relations with one another.

Aside from the current rh/fc java team, Paul Nasrat and Ville Skyttä
spent several months of their lives as core JPackage contributors, and
are probably as qualified as me (if not more) to comment on all this.

Anyone with delusions like "all this dependencies on JPackage suck,
let's dump the FC/JPP relationship and do all the packaging within
Fedora with our own conventions" is cordially invited to join JPP a few
months to get a direct experience on what packaging Java actually means
in terms of work.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20060714/e7a78ea6/attachment.sig>