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