(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 <[email protected]>
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 [email protected] for discussions and questions.
