Bug#858655: Please move Java dependencies to libreoffice-java-common
Hi,
On Mon, Mar 27, 2017 at 02:57:58AM -0400, Daniel Richard G. wrote:
> What about the hard dependency of "libreoffice" on lo-java-common? This
> package is just a dependency of components that need Java, so it is not
> appropriate for the metapackage.
The metapackage is supposed to install (mostly) everything.
This includes the Java stuff.
Think of people wanting to install extensions (which happen to be written in
Java more often than I'd like it but it's a fact...).
That installation would fail with a non clear message if the Java support is
not there. -> Bad.
We had that "fun" in the past...
> Also, shouldn't "libreoffice" Recommends: lo-report-builder rather than
> Depends: lo-report-builder-bin? (lo-r-b-bin is a support package that is
> not usable by itself and so doesn't belong in the metapackage; lo-r-b is
> the useful package, but it requires Java and so should only be
> recommended.)
It's totally irrelevant whether it's installed or not for your case and I
already said why this one is in the metapackage.
> > > My apologies, I left out an important bit in that paragraph: to also
> > > move all the JRE dependencies to lo-java-common. So when LO as a
> > > whole is being installed, the only package that actually pulls in
> > > the JRE is lo-java-common.
> >
> > As I said, libreoffice-java-common just contains libraries.
> >
> > https://www.debian.org/doc/packaging-manuals/java-policy/x126.html
> >
> > "Libraries must not depend on a Java runtime."
>
> Ah, but that policy also says
>
> Java libraries packages must be named libXXX[version]-java (without
> the brackets), where the version part is optional and should only
> contain the necessary part.
>
> So lo-java-common isn't _really_ a Java library package :-)
As I said, that wording would be for the public unoil.jar. But the spirit
remains :)
> What I am suggesting is for the JRE dependency to be expressed via the
> lo-java-common package.
I understand what you want :)
> If it helps, imagine that there is a "libreoffice-jre" package, with this
description:
>
> This dependency package points to a Java runtime that is compatible
> with LibreOffice. Any LibreOffice component that requires Java will
> depend on this package.
God, please no.
> In this formulation, it is a separate package from lo-java-common, and
> contains no actual Java files (as the package exists only for the
> dependency). The reason why I did not suggest this approach is because
> there is no reason why you would want to install only one of lo-jre or
> lo-java-common, so there is no reason to have two separate packages.
Good.
> (However, declining the JRE is not a good enough solution, because if
> you do have a JRE installed for other purposes, then it becomes much
> harder to tell apt-get to decline all the LO Java stuff.)
It's not hard at all. Just don't install the metapackage and install
only the packages which don't need Java.
> > But this discussion is artificial, if there was a Recommends: there
> > *any* module which needs Java needs *extra* Depends on it as - as you
> > say yourself - one can install without Recommends and _THEN_ the
> > package would be broken. So any package requiring Java would still
> > needs to Depend on Java _in addition_.
>
> Ah, yes, you are correct. lo-java-common would need a hard dependency on
> a JRE, or else the latter can be declined and packages will break
> (unless they have their own JRE dependencies).
>
> On the other hand, it _is_ possible to achieve a similar effect with
> separate lo-java-common/JRE dependencies. But then it is necessary to
> always have the two dependencies in tandem---if a package Depends: on
> one, then it Depends: on the other. If it Recommends: one, then it
> Recommends: the other. There can't be any instance where a package
> depends on only one of the two, or has a hard dep on one and a soft dep
> on the other.
>
> I would prefer to have a single dependency instead of two parallel ones,
> but maybe this approach is more to your liking?
No, how it is right now is my liking ;) (well, it's not ideal, but the
alternatives are worse.)
Regards,
Rene
Reply to: