Bug#733996: Generate a ‘closure-compiler’ binary package for the compiler program

[Ben Finney]

(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 <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20140105/06474472/attachment.sig>