(Trimming the list of recipients somewhat) On 05-Jan-2014, gregor herrmann wrote: > On Sun, 05 Jan 2014 11:50:36 +1100, Ben Finney wrote: > > * a manpage for the command (required by Debian policy), which is > > extraneous for a libary package > > That's not my interpretation of Debian Policy, or maybe I > misunderstood you.
By placing the parenthetical where I did, it was intended only to apply to “a manpage for the command”: i.e. every command in ‘/usr/bin/’ needs an explanatory manpage. The statement about library packages isn't an implication of the policy. > So if closure-compiler can be executed it needs a manpage, no matter > in which (kind) package under which name it is. Right, which means: > > No package providing a command should be empty; there needs to be the > > command, and a manpage, at least. So this objection doesn't seem to apply > > for bug#733996. > > My understanding of the idea [0] was that the new closure-compiler > package would only contain a symlink (and a dependency), since that > actual "command" is the same jar as what is in > libclosure-compiler-java [1]. Yet the command also needs a manpage. A separate ‘closure-compiler’ package specifically for that command would also be the right place to have the command's manpage; hence the binary ‘closure-compiler’ package would not be empty. > If that's the case, it still feels a bit odd to me. There's also the fact that the ‘closure-compiler’ would have quite different dependencies from ‘libclosure-compiler-java’, so that is also a good reason to have distinct real binary packages. See Bug#733996. > If I misunderstood the situation or there are other ideas on how to > separate a binary and a library package, that's fine for me :) (I think by “separate a binary and a library package”, you mean “separate binary packages for a command and a library”. Apologies if I've misunderstood you.) I'm not familiar with packaging Java libraries, but I would think it sufficient to do something like what I've described in Bug#733996. For example, the ‘debian/control’ would have: Source: closure-compiler … Package: libclosure-compiler-java Section: java Suggests: libclosure-compiler-java-doc Description: JavaScript optimizing compiler — runtime libraries … Package: closure-compiler Section: devel Depends: default-jre-headless, libclosure-compiler-java Description: JavaScript optimizing compiler … Package: libclosure-compiler-java-doc Section: doc Suggests: libclosure-compiler-java Description: JavaScript optimizing compiler — API documentation … The binary ‘closure-compiler’ package would install: * the ‘/usr/bin/closure-compiler’ command (perhaps a symlink, as now) * the manpage (not yet written?) * the ‘README’ file (or some subset the describes running the compiler from the command line) * maybe others My main point in responding to your message is: the binary ‘closure-compiler’ package will not be empty. It will need to install files distinct from the ‘libclosure-compiler-java’ package. -- \ “I'm having amnesia and déjà vu at the same time. I feel like | `\ I've forgotten this before sometime.” —Steven Wright | _o__) | Ben Finney <b...@benfinney.id.au>
signature.asc
Description: Digital signature
__ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.