webCDwriter: Building with non-free tools; DFSG-conforming?. Dependencies vs Suggestions
Following a suggestion from my sponsor, i place this question so that you
can point me in the righ direction.
( a bit long, sorry )
I have packaged webCDwriter [
http://wwwhomes.uni-bielefeld.de/jhaeger/webCDwriter ] ( and updated three
upstream versions since I started! :-| )
Package names: webcdwriter, cdrecord
Apart from some minor tweaking ( including, maybe, splitting further into
an arch-independent package -- webcdcreator ) in the packaging and maybe
working around some "limitations" (bugs?) in the upstream sources, it is
mostly finished [ latest version usually available at deb(-src)
http://devel.adv-solutions.net/debian (un)stable main ].
However, I have a little problem:
- The package contains a couple Java applets
- jdk is in non-free ( therefore, the package belongs in "contrib"
[according to Policy], where it is classified by my 'control' file )
- upstream provides pre-compiled and pre-signed JARs, which are used if a
working JavaC is not found.
The question is:
- Is jdk a *real* build-dependency ?
( it is currently listed as "Build-Recommends" [ i know that is a
non-existent tag, BTW ]
- Will the autobuilders/build-daemons install javac ?
- Shall I really force the building process, considering they are
arch-independent ? Can I not simply use the upstream-supplied JARs ?
( Source Code for everything is provided [of course!], licensed under GPL2 )
And more important: which is the rationale behind the decision? ( so that i
can decide by myself in the future ;) ).
Which are the sections of Policy, Developer's Reference, etc applicable here?
Shall I ask an changes from upstream?
As a side note: the "main" program will not work ( performs runtime checks
against this ) if certain versions of *mpg123* ( mpg321 will not produce
correct results ), vorbis-tools, cdrdao, dvd+rw-tools aren't installed.
However, there are configuration variables which control their usage ( so
that they are effectively not used if configured that way ).
From a correctness point of view, I have marked theses packages as
"suggested" and acted in that way in the 'config' scripts. Shall I work on
source patches which enforce this "correct" bahaviour and submit them
upstream ( even though that delays the release process ) or else mark them
as dependencies and forget about it, at least until a future date /
upstream revision ?
Any pointers, comments, suggestions, whatever appreciated.
Thanks in advance
Regards,
J.L.
Reply to: