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

Bug#858655: Please move Java dependencies to libreoffice-java-common



Hi Rene,

On Sat, 2017 Mar 25 23:54+0100, Rene Engelhard wrote:
>
> Because you install the metapackage which installs those "all
> components". And libreoffice-base (well, its internal database) _is
> written in Java_.

My intention is to install LibreOffice as a whole minus the Java stuff.

As I understand it, some LO stuff is in Java, but not much. The Java
stuff is notorious for being slow, and as I'm not aware of anyone at my
site needing it, I want to not even install it.

> Yes. Note that "libreoffice" DOES NOT depend on the JRE or Java
> libs itself.
>
> That's pulled in by -base and -report-builder.

Of course. I don't care too much which specific components need Java
(unless e.g. Writer one day starts requiring it); I just want to tell
apt-get "no Java!" and let it do its thing.

> > Let's try installing sans what appears to be LibreOffice's main Java-
> > dependency package:
>
> It's the base stuff without which Java stuff inside LO won't work.
> Basically anything needed for Java in LO is inside that one (besides
> those which belong into the UNO runtime environment or have
> specializied packages).

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.

> > This doesn't make much sense to me. I can't decline installation of
> > lo-java-common, but I can decline default-jre, yet some of the
> > resulting
>
> It does make perfect sense.

How are the *.jar files in lo-java-common useful without a Java runtime?
It doesn't make sense to me for the dependencies to say that these files
are required, when the component required to use them does not need to
be installed.

> > installed packages are useless (lo-report-buildir-bin without
> > lo-report-builder?) or at worse broken.
>
> lo-report-builder-bin without -report-builder installed is not
> breaking stuff. It's more or less a noop. It's installed because in a
> standard upstream install it's in "core" packages afaicr (witgh -report-
> builder being in a extra "package" there, too)
>
> In fact, the RB is in report-builder and report-builder-bin is just
> arch-dep support libraries and it appears only then.

Installing a support package that is not used is better than installing
a broken package, but it is still the result of inaccurate package
dependency information. It doesn't make sense to install just lo-r-b-bin
and not lo-r-b.

(This particular issue is more a symptom of the problem, than a real
problem in itself.)

> > Looking through the dependencies in the various LibreOffice
> > packages, one issue I see is that several of them depend directly on
> > default-jre (or more specifically, "default-jre | openjdk-8-jre |
> > openjdk-7-jre | openjdk-6-jre | gcj-jre | sun-java5-jre | sun-java6-jre
> > | java5-runtime | jre") as well as lo-java-common, when the JRE
> > dependency should in fact be redundant alongside lo-java-common.
>
> No, why should simple support libraries (and this is -java-common)
> depend on a JRE? Stuff needing a JRE should depend on a JRE, not some
> "random" package containing just libraries. Doing this causes many
> issues also for normal Java library packages in Debian. Count this
> package as having only many LO-internal Java libraries.

The dependency need not be a Depends:... Recommends: would be fine too.

> > What I would like to see is for all the various LibreOffice packages
> > that can/must make use of Java to Depends:/Recommends:/Suggests:
>
> That is *exactly* what we have right now.

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.

Think of it as a bottleneck in the dependency graph. This then makes it
easy to pull out that dependency.

> libreoffice installs everything you need. Including a JRE.
>
> If you don't want it/want more control, install the various modules
> yourself. The only one where you really do need Java is Base (and
> the script providers mentioned above and the Java-based extensions
> of course)

"libreoffice" already does not have a hard dependency on a JRE, so there
is no need to give up the metapackage abstraction. I can do without Base
if that absolutely requires a Java runtime, and the other stuff isn't
interesting.

(I don't want to start worrying about the list of all the various
LibreOffice components, because that defeats the purpose of having
metapackages.)

> > lo-java-common, and then have lo-java-common Depends: default-jre et
> > al. That way, when installing LibreOffice, I can decline lo-java-
> > common, the JRE won't get pulled in, and no LibreOffice package that
> > requires Java (or is related to one that does) will get installed.
>
> If you install "libreoffice" you install Base.
>
> Which 100% needs Java right now (because of -sdbc-hsqldb). Of course,
> if you disable Recommends:, you won't see it, but it's there.[1]

Uh... you're aware that it's possible to install a package with some
(neither all/none) of its Recommends: being applied, yes?

> The current structure is a result of long thinking about it and
> shuffling around various times and you need a compromise there.
> Knowledgeable users can avoid Java by avoiding the libreoffice
> metapackage and/or the packages which need Java,

Neither of those should be necessary; the package system is powerful
enough to produce a sensible result. It does, however, need dependency
information that is geared toward achieving a sensible result.


On Sun, 2017 Mar 26 00:10+0100, Rene Engelhard wrote:
>
> One could argue -java-common should suggest or recommend a JRE, but I
> am a bit wary of that, as said, you don't _need_ it for "normal" LO
> operation.

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.


Reply to: