From Mandriva Community Wiki

[edit] JPackage policy proposal (work in progress)

JPackage provides a cross-distribution Java Packaging standard. We have some problems with JPackage that causes incompatibilities and breakage with Mandriva. This leads to problems where it's adviced against using jpackage at all and that we fork every package in our repositories where one has to manually sync it for every package. Causes for breakage doesn't seem to be intended and it's mostly related to the lack of policies, so the ideal world where we can use these packages from upstream without having to fork them and maintain our own changes locally isn't impossible to obtain, on the contrary it should be fairly easy and it would also benefit other distributions. When we've reached this target we can just add jpackage repository to our own mirrors without these worries.

[edit] Current problems with JPackage in Mandriva (by David Walluck?):

• Packages in JPackage are built with a non-free (Sun) compiler, and as such, they really have no possibility of making it into contribs proper, much less into main. This is a first step at getting much-requested packages such as eclipse and tomcat5 into main.
• Although Mandriva has mirrored JPackage for some time in the jpackage section, the mirror is incomplete and not up to date. Even if this was fixed, it would not change the first point.
• JPackage is not well suited for native archs. For example, JPackage does not provide packages for any Mandriva archs besides i586.
• Rebuilding with gcj may allow native compilation, which should allow substantial speed gains over using gij with the JPackage noarch packages.
• Repackaging for Mandriva may allow tighter integration. For example, JPackage servers ship with LSB-compatible initscripts that do not contain Mandriva modifications.
• As packages are being ported over, packaging bugs in the upstream version will be fixed and (ideally) make their way back upstream.

Thus, packages in JPackage will have to be rebuilt with the gcj 4.0 compiler (available since gcc4.0-4.0.0-2mdk). Rebuilt packages should contain as few changes as possible. Any appropriate changes should be pushed back upstream.

[edit] Policy proposals, ideas, problems etc. to solve this (by Per Øyvind):

• Macro

A lot of conditional behaviour are added to a lot of different packages, not only does one try to add every hack needed for each distro, but also for every release of these distros. These are often quite hackish and pollutes packages making it hard to read and understand, some times they even break packages. Such distro/release-dependent behaviour should be moved to (distro-specific) macros, this way they will be easier to maintain, understand, be consistent so that every packager uses their own way to do these things and to be able to easily exclude them.

• %ghost usage

A lot of packages uses %ghost in addition to update-alternatives to ensure that these files gets "owned" by packages (added to rpm database). %ghost is not by far safe, a %ghost file will be removed whenever removing a package who owns it without regard of any other packages who owns it, to cope around this additional hacks has been added to package scriptlets to recreate the files that gets removed. This is often done in various ways and often leads to these symlinks not being updated. I haven't found the real root of the cause, whether packaging, rpm or update-alternatives is to blame, but it's anyways no huge gain in this and it adds a lot of hacks so I see two solutions to this; a) drop this completely (I favour this as there's no huge benefits of having it), b) fix rpm to either optionally not remove %ghost files at package removal or check for ownership by other packages before removal (I'd really like to see this, but both would require rpm to be patched which would require a lot of efforts & cooperation outside of JPackage etc., so probably not something one would want for now). A final alternative way to solve this is to add some macros for this so that way distributors could choose how to deal with this, not that worthwhile anyways IMO.

• JPackage releases

JPackage release numbering is kind of confusing and inconsistent(?). A 'current/unstable' branch might be nice and rather do a fork for every new release in stead of having it versioned as upcoming release.

• Release tags

Jpackage uses %{release}jpp as release tag, Mandriva uses %{release}mdv%{distrelease} (ie. 1mdv2007.0) as release and other distros might not have a suffix at all. Mandriva uses it's own %mkrel macro to handle this, you can define your own suffix for %mkrel to use, thereby allowing for distributions to define their own. We could also use this to define jpp release too (ie. 1jpp1.7).

• Consistent behaviour, formatting, style etc.

A lot of different ways to do things etc. is done in jpackage, this makes it often harder to understand what people do and pollution of spec files. Trying to stay consistent would be very nice, a skeleton.spec file aids in this.

• Various paths for variables

Different ditros might use different paths for standard variables, ie. %_localstatedir seems to be different on Mandriva, RedHat & SuSE. One way to cope with this could be to redefine them to be the same for all for jpackage packages, but this might add confusion for packagers as they might not be aware of it and takes it for granted that the variable might be different. It should be looked into the reasoning behind this and if it makes sense to use these different paths for each distro it should be done, if not it should be done the "hard way".

• Lack of proper infrastructure/buildsystem

Submitting packages is a drag, one has to build the packages by oneself and also upload them manually. The process involves too much manual interaction and you also have to submit a new package for every change you make (ie. you can't make a change without uploading). An automatic process with the following requirements should be in place:

• • Automatic rebuilding

Ensures packages gets built properly with the correct buildrequires without anything not intended

• • Possibility to submit work through cvs/svn
  • Possibility to commit changes without having to do new release
  • +++
  • Release structure/branches:

For Mandriva who want to integrate packages properly in distro and also to maintain and support packages for stable releases, it's required that jpackage's releases and their scedules doesn't affect eachother, same goes for other distributions. Ie. JPackage needs to stable releases just as well as us, but we also would like for a -devel branch that never gets frozen which all distributions work against (ie. JPackage, RedHat, SuSE, Mandriva). As subversion is used it's trivial for other distributions to integrate it with their systems too. Mandriva offers it's infrastructure for this task which would satisfy all these requirements and also also allow for their developers to easily contribute to jpackage.