[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#119386: libgcj2 includes /usr/bin/gij-3.0



yOn Tue, 13 Nov 2001, Matthias Klose wrote:

> Adam Heath writes:
> > Package: libgcj2
> > Severity: serious
> >
> > Library packages should not include binaries.  Please see policy section 11.3.
> >
> > ...
> >
> >    If  your package has some run-time support programs which use the shared
> > library you must not put them in the shared library package. If you do that
> > then you won't be able to install  several  versions  of the shared library
> > without getting filename clashes. Instead, either create a third package for
> > the runtime binaries (this package might typically be named libraryname-
> > runtime; note the absence of the soversion in the package name), or if the
> > development package is small you may include them in there.
>
> sorry, but this sounds like nonsense for the libgcj2 package. There is
> one binary in libgcj2 called gij-3.0. A libgcj3 package will never
> contain a gij-3.0 binary, so what is wrong in this case? OTOH we still
> have a conflicting file /usr/share/java/libgcj.jar (not a binary),
> which probably could be moved to /usr/share/java/gcj-3.0/libgcj.jar.

Conformity?  This is different that the way other java packages work, in
addition to gcc proper.  libgcc doesn't contain a gcc-3.0 binary.

Additionally, apt-get install gcj gij looks sane, but apt-get install gcj
libgcj2(to get gij) doesn't.  Users shouldn't be concerned about knowing which
library to install, but only about which binary they need.


> maybe the packaging is contrary to the text of the policy, but not to
> the intention of the policy.

But this is not a runtime support binary.  gij-3.0 uses the library, the
library doesn't use gij-3.0.




Reply to: