[Mageia-dev] Java-Policy first draft published

[Michael Scherer]

Le jeudi 27 janvier 2011 à 02:40 +0100, piep a écrit :
> Refection about Java_Packaging_Policy : what about a jpackage project 
> for mageia java based rpm ?
> 
> like others I am still a "padawan" packager, but I also plan to work on 
> java (and music) packages
> 
> I follow this thread with interest for few days and I wonder why nobody 
> thinks to just import java packages from jpackage repositories ?

Because we already use their rpms. And that's a complex mess of
dependencies, with unneeded complexity.

For example, if you look at
svn://svn.mageia.org/packages/cauldron/jakarta-commons-lang/current/SPECS/jakarta-commons-lang.spec
, you can see 
1) the copyright of jpackage ( hence my point, but check any java
package )
2) it support gcj and non gcj ( ie twice the work if we want to test )
3) a weird release ( 2.3.4 )

4) various %post that should have been converted to trigger ( but since
it is not uniform on all distro, they prefered to cut and paste ).

Another issue is they package several version of the same software
( like 5 releases of groovy, 3 versions of junit , etc ). This is
something requires more ressources.

> 1) For many years jpackage.org project provides strong rpm packages of 
> java based applications. These packages are used on the professional 
> platform : Red Hat Enterprise Linux.

Last time I remember, people from Jpackage were not happy because RHEL
people took their rpms and integrated them in Fedora. So I think people
on RHEL use RH rpm, not the one from jpackage.

> Despite the arguments why Mandriva developers left the jpackage project 
> to build their own java packages.
> http://wiki.mandriva.com/en/Java_Packaging_Policy#Compatibility_with_proprietary_Java_stacks 

Well, what is not written there is the java stack of Mandriva was done
mainly by David Walluck, who is .. a jpackage member. And jpackage was
also partially founded by Guillaume Rousse, who also left the project
because they were aiming for too complex and unmaintainable goals.

After David was hired by RH, Alexander Kurtakov stepped to maintain, to
be also hired by RH. The only Ansii fixed some stuff, mainly because he
needed to do.

> 	We are at the beginning of a new rpm based distribution. It would be 
> stupid and suicidal to work on our own java packages and reinvent the 
> wheel again and again. 

No, what would be suicidal is to keep the current java packages, done by
jpackage whose goal do not correspond to ours. 

We are using the jpackage rpms, check the specs. So if we do have
problem in rebuilding the rpms, using more jpackage rpm do not seems
like a solution, except if the problem is "We have too much free time".


> If we want Mageia becomes a major distribution on 
> java application servers also, we have to consider jpackage as source of 
> java packages. Then we can concentrate our java packagers to improve the 
> "time to market" of jpackage applications and on  desktop application 
> (tuxguitar, sweethome3d, JOSM, homeplayer etc..) and all java 
> application that lack in jpackage  and why not try to provide them to 
> jpackage.

Personally, I do not want Mageia to become a major distribution on java
application servers, I want it to be sustainable. And sustainability as
clearly demonstrated by previous attempts is quite difficult to achieve
by using jpackage rpm. So let's start simple, we will have the time to
grow later.

Java was a weak point on Mandriva, and I think that seeing the problem
twice is enough to not want to see it a 3rd time.

Their goals differ totally from ours. First, they still aim to be usable
on more than one platform, which usually mean "be unintegrated on every
platform". In practice, they seems to rather be "usable only on RHEL",
but well. There would be various technical issues, like keep specs in
synchronisation, etc, various organizational issues like not being able
to decide our policy without asking to people outside of our
organisation, or having to handle out of our svn packages, etc.

So let's already take care of what we have. Once packager have
demonstrated that the 400 packages will not bitrot alone in the svn,
then we can start to think importing more IMHO. Pushing more rpm when
the foundation is not maintained is simply a bad idea, like constructing
a house on the sand.

> 6) So why don't we consider "jpackage" with the new eye of a new distro 
> and consider it as an external java application repository like we 
> already use "plf" ?
> Why don't we work closer with the jpackage team to improve the urpmi 
> connection ?

PLF was mainly done by mandrake linux people aiming to integrate with
mandrake linux, and quickly shared src.rpm, followed mandriva policies,
contributed to Mandriva, etc.

Jpackage was made based on the (IMHO flawed) assumption that the only
issue that prevented packages sharing was "binary compatibility", and
that it was solved by jvm. Both affirmation are quite wrong, as there is
lots of others problem to solve ( like rpm version, various choices made
by distribution based on their policy ).

So why don't we consider with the new eye of a new distro ? Because we
are not a new distro, made by people with new eyes, we are experienced
people ( at least, I consider myself as experienced ), trying to keep
what worked of a older distro, and changed what didn't. 

We already tried syncing with jpackage, either by offering their rpm on
mandrake mirrors ( circa 2004 ), or by importing them ( circa
2007/2008 ). It didn't worked as well as you seem to think. And now, if
it work fine on RHEL, that's mainly because that's tested on RHEL only
( as almost everybody there is having a @redhat.com email ).

-- 
Michael Scherer