[Mageia-dev] Java-Policy first draft published

Thu Jan 27 04:39:18 CET 2011

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