Changes in Java packaging guidelines - RFC

[Alexander Kurtakov]

> On Wednesday 03 November 2010,  Ville Skyttä  wrote:
> > On Wednesday 03 November 2010, Stanislav Ochotnicky wrote:
> > FYI the versionless jar/javadocs files are now in the draft (thanks for
> > the suggestion, somehow none of us thought of that)
> 
> Thanks for considering it.
> 
> > But keep those comments coming, we'll try to keep working on the
> > guidelines to reflect current needs of packagers.
> 
> Some other things off the top of my head, in no particular order:
> 
> 1) I'd like to see crosslinking of javadocs at least a SHOULD, and I
> wouldn't mind a MUST at all.  I'm also leaning towards making it a MUST
> for javadoc packages that crosslink with other javadoc packages require
> the ones they crosslink with.
> 
There is no sane way to make javadoc crosslink in a sane way, i.e. without 
patching builds. That's why I would say let's postpone this until we can tell 
packagers HOWTO do it.

> 2) Regarding wrapper scripts, I'd like to point out the %jpackage_script
> macro for creating them.  Here's one example of it in action:
> https://bugzilla.redhat.com/attachment.cgi?id=457277
> Also, most invocations of it will want to set the last argument of it to
> true (such as in the example above) to make jpackage-utils stuff prefer a
> JRE over a full Java SDK (assuming of course that they work with just a
> JRE installed and don't require the full SDK) to avoid problems like
> these:
> https://bugzilla.redhat.com/show_bug.cgi?id=461683
> https://bugzilla.redhat.com/show_bug.cgi?id=498831
I didn't know about this macro. We should definitely document it on the wiki 
and add it as tip to the guidelines.

> 
> 3) In my opinion, the whole alternatives setup in the JRE and SDK packages
> should be purged.  It's a relic from times that are long gone, and at the
> moment causes just complexity and possibilities for breakage; it kind of
> even encourages breakage by giving people the option to easily switch
> between _incompatible_ java implementations (e.g. versions) for the system
> default Java, breaking programs' expectations.  environment-modules would
> sound like a more appropriate solution for switching the Java
> implementation when needed. I'm not holding my breath for this to happen
> too soon, but hope that it sometime will.
There are other way more important things to fix and being able to switch java 
is still usable in a number of cases (despite the problems it causes).

Alex