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
