> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel