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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
