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 request. 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>
signature.asc
Description: Digital signature
