Bug#858655: Please move Java dependencies to libreoffice-java-common
On Sun, 2017 Mar 26 10:12+0200, Rene Engelhard wrote:
>
> > Right. I'd like to be able to say, let's not install that package
> > (lo-java-common), and end up with a clean install of LO sans Java
> > stuff.
>
> You can do that right now, too. Just avoid the Java-using modules. You
> already were on the right track, except that as you say
> -wiki-publisher missed the JRE depends and the script-provider-*
> missed the -java-common depends.
>
> That will be fixed.
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.
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.)
> That -script-provider-{bsh,js} don't have the Depends: is a bug. That
> is acknowledged and will be fixed.
Okay, I am glad that we are squishing bugs :)
> > 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 :-)
What I am suggesting is for the JRE dependency to be expressed via the
lo-java-common package. 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.
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.
> 100% as said above was admittedly oversimplicating as it only applies
> to the hsqldb driver...
>
> This is a compromise. One might want no Java (as you) and thus I
> didn't want to force it on anyone in -base itself.
>
> E.g. Because you use Firebird or connect to MySQL or PostgreSQL via
> Base.
Yes! My users would much sooner use MySQL/Postgres than that
hsqldb thing.
> So I only recommend the hsqldb driver in base-drivers. Recommends:
> installing is per default on and people who disable it (should) know
> what they do and eventually can install -sdbc-hsqldb theirselves.
Yes, this is good. Of course, they may "disable" it not by declining
hsqldb directly, but by declining installation of the JRE that
hsqldb requires.
(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.)
> > Having lo-java-common Recommends: a JRE would be fine---as long as
> > that was the only JRE dependency, that would then allow me to
> > decline all Java- requiring components by declining lo-java-common.
>
> If at all, only a Suggests: (see above)
>
> 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?
Reply to: