On 30-Dec-2013, Thomas Koch wrote:
> closure compiler is also a library dependency, e.g. of gwt. It might be a
> good idea to provide two binary packages, one for the library jar and
> another one for the manpage + executable.

I have reported bug#733996 <URL:http://bugs.debian.org/733996> for this

On 30-Dec-2013, Daniel Pocock wrote:
> On 30/12/13 21:03, tony mancill wrote:
> > I'm not sure if there is a best practice for executable JARs that are
> > used in both contexts, but adding an additional binary package doesn't
> > seem too bad.

It seems quite appropriate to me. Especially since Lintian (IMO correctly)
warns when a Java library package depends on a JRE package.

> I'll change my own packages to depend on closure-compiler when it exists

That's what I'm hoping for also.

On 31-Dec-2013, gregor herrmann wrote:
> Can't this be solved with a simple
>     Provides: closure-compiler
> in the libclosure-compiler-java package?
> (Or the other way round.)

That doesn't address:

* a manpage for the command (required by Debian policy), which is
  extraneous for a libary package

* separate API documentation for the library, which is extraneous for a
  command package

* better focussed dependencies: the command package needs a JRE, the
  library package should not have that dependency

> Having a de facto empty package doesn't seem very appealing to me.

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.

 \        “A life spent making mistakes is not only most honorable but |
  `\          more useful than a life spent doing nothing.” —anonymous |
_o__)                                                                  |
Ben Finney <b...@benfinney.id.au>

Attachment: signature.asc
Description: Digital signature

This is the maintainer address of Debian's Java team
Please use
debian-j...@lists.debian.org for discussions and questions.

Reply via email to