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.