Java headless bugs

[Stanislav Ochotnicky]

Jerry James <loganjerry at gmail.com> writes:

> I've got a few comments and questions about the recently filed bugs asking
> us to switch from Requires: java to Requires: java-headless.  First, the
> bugs list some web pages to view for more information.  Number two on that
> list is this:
>
> https://fedoraproject.org/wiki/Packaging:Java\#BuildRequires_and_Requires
>
> which has a really unfortunate backslash in it.  People clicking on that
> link get a "sorry, no such page" message from the web server.  It should
> have been this:
>
> https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires

Yup, my bad. I guess this was added automatically when I was
copy-pasting from wiki where I was preparing the message. The tracking
bug has correct link at least...

> Second, the bugs talk about this as a proposed guidelines change, yet
> https://fedoraproject.org/wiki/Packaging:Java now talks about it.  Doesn't
> that mean that this is an official guideline, not a proposed change to the
> official gudelines?

I believe you misread it:
  See tracking bug #1067528 or Headless Java change proposal[1] and Java Packaging
  guidelines[2] for more details about this change.

The work "proposal" was wrt Headless Java change. Fedora doesn't usually
require immediate change to all packages in repositories with each
guideline change. However for Headless Java change to have any effect
most packages have to migrate. I re-read the bugs and I don't see how it
could be read as "proposed guidelines change". I had a few people read
the messages before filing the bug and it seemed to be OK as well.

In any case, yes the official guideline is prefer "java-headless" if
your library/app can use it. Sorry for the confusion.


> Third, developers are offered two options in those bugs: (1) don't do
> anything and an automatic tool will make the change for you on or after
> March 17, or (2) make the change to java-headless yourself.  I have one
> package for which I need a third option: tell the automated tool that this
> bug was filed in error, the package really doesn't work with java-headless,
> and don't touch the package.  I realize that I can mark the bug as assigned
> and leave it open indefinitely, but I'd rather have some option for closing
> the bug, please.

Quoting from the bugreport:
 Automated tool will not touch bugs that are not in NEW state.

If you close the bug (whatever reason) the automated tool will not touch
your package(s). I guess I should have added "close" as valid way to
avoid it.

> Slightly off-topic: fedora-review is telling packagers NOT to add
> "Requires: jpackage-utils" to javadoc subpackages because that is added
> automatically, but I see no mention of this on
> https://fedoraproject.org/wiki/Packaging:Java.

Guidelines state that package must have "R: jpackage-utils" because it
contains filesystem (/usr/share/javadoc directory). If the requires is
generated automatically all the better but that's not the guidelines
scope IMO.

I don't see this as much of a problem. Guidelines are there to ensure
packages have proper requires. Tooling can improve faster than
guidelines. It's not breaking anything and f-r is a guidance tool. It's
not guaranteed to comply with guidelines 100%, maintainers should know
guidelines in any case and behave appropriately :-) Basically it boils
down to understanding "why" some f-r check fails. We try to point out
potential improvements/fixes and sometimes the suggestions might be
incorrect. For example if you wanted to keep the same package on EPEL6
and Fedora where EPEL6 wouldn't generate the jpackage-utils requires.

Hope this clears up everything, if not drop by #fedora-java IRC

--
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140224/cde5b467/attachment.sig>