Bug#858655: Please move Java dependencies to libreoffice-java-common
On Wed, 2017 Mar 29 09:58+0200, Rene Engelhard wrote: > > Or one can Recommends: it in libreoffice. Yeah. Well, I guess that would let me do what I originally wanted... # apt-get install libreoffice libreoffice-java-common- (note the minus at the end) to install LibreOffice without the Java stuff, even if a JRE is already installed. > And what if they decide to remove it later? And autoremove kicks in? > They will have their stuff break suddenly. If they remove packages that provide X, then things that require X will break. This is a fact of the universe, people have to learn this sooner or later. > Still that is not obvious, and even newbies sometimes get told you > disable Recommends: install.. That was *your* argument when we came up > with -base-drivers and -sdbc-hsqldb. If they disable Recommends:, then they don't get the JRE, and Java stuff breaks anyway. The only way to change this is to make "libreoffice" hard- depend on a JRE, and (thankfully) you've already said that you don't want this. > I will _think_ about just Recommending java-common. It may not be the cleanest solution IMO, but this would be enough to make LO installation sane for me. > But that is it. In no way will every Java dependency move to java- > common (and that is what this bug is about, if you wanted > something else you would have written something else), because > that would be bogus. Given your role as maintainer of the LO beast, I thought you would want to simplify the dependency tree as much as possible. > And this will be my last mail to this "bug". That is okay with me. Cheers, --Daniel -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman.
Bug#858655: Please move Java dependencies to libreoffice-java-common
Hi, On Tue, Mar 28, 2017 at 11:09:39PM -0400, Daniel Richard G. wrote: > On Tue, 2017 Mar 28 09:35+0200, Rene Engelhard wrote: > > > > > > If LibreOffice is installed without Java runtime support, then how > > > is the failed installation of Java-based third-party extensions a > > > problem? That is exactly what should happen. > > > > But people out there don't know what their extension is written in and > > (often) don't know about java-common or so. Thus the metapackage gets > > it in because newbies out there just do apt-get install libreoffice. > > That command already pulls in the Java stuff, including lo-java-common, > because the metapackage Recommends: packages that require Java (like > lo-report-builder). > > You already solved this problem without Depends: lo-java-common. Or one can Recommends: it in libreoffice. Yeah. And what if they decide to remove it later? And autoremove kicks in? They will have their stuff break suddenly. Still that is not obvious, and even newbies sometimes get told you disable Recommends: install.. That was *your* argument when we came up with -base-drivers and -sdbc-hsqldb. I will _think_ about just Recommending java-common. But that is it. In no way will every Java dependency move to java-common (and that is what this bug is about, if you wanted something else you would have written something else), because that would be bogus. And this will be my last mail to this "bug". Regards, Rene
Bug#858655: Please move Java dependencies to libreoffice-java-common
On Tue, 2017 Mar 28 09:35+0200, Rene Engelhard wrote: > > > > If LibreOffice is installed without Java runtime support, then how > > is the failed installation of Java-based third-party extensions a > > problem? That is exactly what should happen. > > But people out there don't know what their extension is written in and > (often) don't know about java-common or so. Thus the metapackage gets > it in because newbies out there just do apt-get install libreoffice. That command already pulls in the Java stuff, including lo-java-common, because the metapackage Recommends: packages that require Java (like lo-report-builder). You already solved this problem without Depends: lo-java-common. > Trust me, we have been there various times and thus why a default LO > install *does* install it. It's not that I don't trust you, it is that this "solution" does not help the problem you are describing. If you try an experimental build without that dependency, "apt-get install libreoffice" will install exactly the same set of packages as now.
Bug#858655: Please move Java dependencies to libreoffice-java-common
On Tue, 2017 Mar 28 08:36+0200, Rene Engelhard wrote: > > > > > That installation would fail with a non clear message if the Java > > > support is not there. -> Bad. > > > > > > We had that "fun" in the past... > > > > So, there are Java-based LibreOffice extension packages that do not > > properly declare their Java dependencies? > > I didn't say "packages"? Extensions from the wild, from upstream, from > LOs extension website _in oxt format_. If LibreOffice is installed without Java runtime support, then how is the failed installation of Java-based third-party extensions a problem? That is exactly what should happen. > > ...are in libobasis5.2-extension-report-builder-5.2.6.2-2.x86_64.rpm, > > not in libobasis5.2-core-5.2.6.2-2.x86_64.rpm. The situation is the > > same in 5.3. > > Hmm, then I misremember and need to dig out again why this was in the > metapackage... I'm curious...
Bug#858655: Please move Java dependencies to libreoffice-java-common
On Tue, Mar 28, 2017 at 03:28:31AM -0400, Daniel Richard G. wrote: > On Tue, 2017 Mar 28 08:36+0200, Rene Engelhard wrote: > > > > > > > That installation would fail with a non clear message if the Java > > > > support is not there. -> Bad. > > > > > > > > We had that "fun" in the past... > > > > > > So, there are Java-based LibreOffice extension packages that do not > > > properly declare their Java dependencies? > > > > I didn't say "packages"? Extensions from the wild, from upstream, from > > LOs extension website _in oxt format_. > > If LibreOffice is installed without Java runtime support, then how is > the failed installation of Java-based third-party extensions a > problem? That is exactly what should happen. But people out there don't know what their extension is written in and (often) don't know about java-common or so. Thus the metapackage gets it in because newbies out there just do apt-get install libreoffice. Trust me, we have been there various times and thus why a default LO install *does* install it. This won't be changed. Regards, Rene
Bug#858655: Please move Java dependencies to libreoffice-java-common
On Tue, Mar 28, 2017 at 01:49:04AM -0400, Daniel Richard G. wrote: > On Mon, 2017 Mar 27 11:01+0200, Rene Engelhard wrote: > > > > 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... > > So, there are Java-based LibreOffice extension packages that do not > properly declare their Java dependencies? I didn't say "packages"? Extensions from the wild, from upstream, from LOs extension website _in oxt format_. > I checked the upstream RPM packages for LibreOffice 5.2. These library > files from lo-report-builder-bin ... > > /usr/lib/libreoffice/program/librptlo.so > /usr/lib/libreoffice/program/librptuilo.so > /usr/lib/libreoffice/program/librptxmllo.so > > ...are in libobasis5.2-extension-report-builder-5.2.6.2-2.x86_64.rpm, > not in libobasis5.2-core-5.2.6.2-2.x86_64.rpm. The situation is the > same in 5.3. Hmm, then I misremember and need to dig out again why this was in the metapackage... Regards, Rene
Bug#858655: Please move Java dependencies to libreoffice-java-common
On Mon, 2017 Mar 27 11:01+0200, Rene Engelhard wrote: > > 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... So, there are Java-based LibreOffice extension packages that do not properly declare their Java dependencies? > > 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. You said, It [lo-report-builder-bin] is installed because in a standard upstream install it's in "core" packages afaicr (with -report- builder being in a extra "package" there, too) I checked the upstream RPM packages for LibreOffice 5.2. These library files from lo-report-builder-bin ... /usr/lib/libreoffice/program/librptlo.so /usr/lib/libreoffice/program/librptuilo.so /usr/lib/libreoffice/program/librptxmllo.so ...are in libobasis5.2-extension-report-builder-5.2.6.2-2.x86_64.rpm, not in libobasis5.2-core-5.2.6.2-2.x86_64.rpm. The situation is the same in 5.3.
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
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?
Bug#858655: Please move Java dependencies to libreoffice-java-common
Hi, oops. On Sun, Mar 26, 2017 at 10:12:01AM +0200, Rene Engelhard wrote: > They are not. If you used one of them (which you probably won't run into > given even the wizards are Java) you get told you want Java. Basically it's [...] are NOT java anymore but python [...] Regards, Rene
Bug#858655: Please move Java dependencies to libreoffice-java-common
Hi,
On Sun, Mar 26, 2017 at 01:18:00AM -0400, Daniel Richard G. wrote:
> 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.
Then install the various modules manually. If you want "libreoffice" you
want "libreoffice-base" which recommends libreoffice-sdbc-hsqlb (as that's
the db engine) which is - as said - written in Java.
> > 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.
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.
But your wish goes further and thus this bug can only be wontfix.
> > > 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.
They are not. If you used one of them (which you probably won't run into
given even the wizards are Java) you get told you want Java. Basically it's
only support libraries for Java extensions and the script provider stuff and
some (minor) filters.
That -script-provider-{bsh,js} don't have the Depends: is a bug. That is
acknowledged and will be fixed.
> > > 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.
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."
(This policy applies to unoil, which is the only public library - where this
applies - here. Yeah, didn't splt it out to a libunoil-java, but if I did this
it would open new can of worms, especially in the C++ libs case right now
put together in one uno-libs3...)
> > 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.
Then don't install the metapackage.
> (I don't want to start worrying about the list of all the various
> LibreOffice components, because that defeats the purpose of having
> metapackages.)
No, it doesn't.
> > > 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?
Yes.
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.
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.
> > 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
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
Bug#858655: Please move Java dependencies to libreoffice-java-common
On Sun, Mar 26, 2017 at 12:10:35AM +0100, Rene Engelhard wrote: > [...] *And* it will also tell people to install libreoffice-java-common [...] Actually that's untrue - the patch is disabled, probably because it didn't apply anymore and it was forgotten to update.. ;/ Regards, Rene
Bug#858655: Please move Java dependencies to libreoffice-java-common
Hi, On Sun, Mar 26, 2017 at 12:01:53AM +0100, Rene Engelhard wrote: > On Fri, Mar 24, 2017 at 07:00:22PM -0400, Daniel Richard G. wrote: > > # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep > > 'jre|jdk|java' > > Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all]) > > > > Hunh, that worked. The lo-java-common package went in, even though it's > > presumably useless without a Java runtime. So what about those > > aforementioned components that supposedly required Java? 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. If LO notices there's no JRE it will tell people. *And* it will also tell people to install libreoffice-java-common if people want/need Java suport and there's no JRE. The necessary mechanism for that is in ure. > > # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep > > 'nlpsolver|report-builder|wiki-publisher' > > Inst libreoffice-report-builder-bin (1:5.2.5-2 Debian:testing [amd64]) > > Inst libreoffice-wiki-publisher (1.2.0+LibO5.2.5-2 Debian:testing [all]) > > > > So nlpsolver didn't go in (reasonable), only the bin package of > > report-builder was installed (huh?), and wiki-publisher went in just > > fine (will that even work in light of its hard dep on lo-java-common?). > > That is interesting, though. They are *extensions* to LO, though, whereas > -sdbc-hsqldb is a _core_ component. But yeah, probably they should depend > on default-jre etc, too - as -sdbc-hsqldb does. -nlpsolver does. Will add a dependency on the JRE to libreoffice-wiki-publisher. That was indeed missing. No idea whether it will make stretch, though. Regards, Rene
Bug#858655: Please move Java dependencies to libreoffice-java-common
Hi, On Fri, Mar 24, 2017 at 07:00:22PM -0400, Daniel Richard G. wrote: > # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep > 'jre|jdk|java' > Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all]) > > Hunh, that worked. The lo-java-common package went in, even though it's > presumably useless without a Java runtime. So what about those > aforementioned components that supposedly required Java? > > # apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep > 'nlpsolver|report-builder|wiki-publisher' > Inst libreoffice-report-builder-bin (1:5.2.5-2 Debian:testing [amd64]) > Inst libreoffice-wiki-publisher (1.2.0+LibO5.2.5-2 Debian:testing [all]) > > So nlpsolver didn't go in (reasonable), only the bin package of > report-builder was installed (huh?), and wiki-publisher went in just > fine (will that even work in light of its hard dep on lo-java-common?). That is interesting, though. They are *extensions* to LO, though, whereas -sdbc-hsqldb is a _core_ component. But yeah, probably they should depend on default-jre etc, too - as -sdbc-hsqldb does. But not -java-common, as outlined in my first reply. Regards, Rene
Bug#858655: Please move Java dependencies to libreoffice-java-common
severity 858655 wishlist
tag 858655 + wontfix
thanks
Hi,
On Fri, Mar 24, 2017 at 07:00:22PM -0400, Daniel Richard G. wrote:
> A regular LibreOffice install has many Java dependencies:
>
> # apt-get -s install libreoffice | grep '^Inst' | egrep 'jre|jdk|java'
Description-en: office productivity suite (metapackage)
LibreOffice is a full-featured office productivity suite that provides
a near drop-in replacement for Microsoft(R) Office.
.
This metapackage installs all components of libreoffice:
* libreoffice-writer: Word processor
* libreoffice-calc: Spreadsheet
* libreoffice-impress: Presentation
* libreoffice-draw: Drawing
* libreoffice-base: Database
* libreoffice-math: Equation editor
It also recommends additional packages (e.g. fonts) in order to match an
upstream LibreOffice install as closely as possible.
Because you install the metapackage which installs those "all components".
And libreoffice-base (well, its internal database) _is written in Java_.
> Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])
> Inst ca-certificates-java (20161107 Debian:testing [all]) []
> Inst java-common (0.58 Debian:testing [all]) []
> Inst openjdk-8-jre-headless (8u121-b13-4 Debian:testing [amd64])
> [long list of Java-related packages elided]
Yes. Note that "libreoffice" DOES NOT depend on the JRE or Java libs itself.
That's pulled in by -base and -report-builder.
> 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).
> 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.
> 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.
> 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.
> (Interestingly, libreoffice-script-provider-{bsh,js} depend on a JRE
> _without_ depending on lo-java-common. Does that make sense?)
That is probably a bug... I'd assume those ScriptProviders need
/usr/share/libreoffice/program/classes/ScriptFramework.jar which
is in -java-common.
> 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.
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)
> 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]
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,
-> wontfix (maybe except the -script-provider-* part, but this bug is about a
greater
wish.)
Regards,
Rene
[1] There's the theoretical possibility to use firebird thus -base recommends
both,
and firebird might be default engine in a future release.
>
Bug#858655: Please move Java dependencies to libreoffice-java-common
Package: src:libreoffice
Version: 1:5.2.5-2
I am interested in the topic of installing LibreOffice without Java.
This is possible, of course, but this bug report is concerned with a
dependency structure that makes this needlessly messy.
A regular LibreOffice install has many Java dependencies:
# apt-get -s install libreoffice | grep '^Inst' | egrep 'jre|jdk|java'
Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])
Inst ca-certificates-java (20161107 Debian:testing [all]) []
Inst java-common (0.58 Debian:testing [all]) []
Inst openjdk-8-jre-headless (8u121-b13-4 Debian:testing [amd64])
[long list of Java-related packages elided]
Let's try installing sans what appears to be LibreOffice's main Java-
dependency package:
# apt-get -s install libreoffice libreoffice-java-common-
[...]
The following packages have unmet dependencies:
libreoffice : Depends: libreoffice-java-common (>= 1:5.2.5~) but it is not
going to be installed
Recommends: libreoffice-nlpsolver but it is not going to be
installed
Recommends: libreoffice-report-builder but it is not going
to be installed
Recommends: libreoffice-wiki-publisher but it is not going
to be installed
E: Unable to correct problems, you have held broken packages.
Darn. Okay, can we install without pulling in the JRE?
# apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep
'jre|jdk|java'
Inst libreoffice-java-common (1:5.2.5-2 Debian:testing [all])
Hunh, that worked. The lo-java-common package went in, even though it's
presumably useless without a Java runtime. So what about those
aforementioned components that supposedly required Java?
# apt-get -s install libreoffice default-jre- | grep '^Inst' | egrep
'nlpsolver|report-builder|wiki-publisher'
Inst libreoffice-report-builder-bin (1:5.2.5-2 Debian:testing [amd64])
Inst libreoffice-wiki-publisher (1.2.0+LibO5.2.5-2 Debian:testing [all])
So nlpsolver didn't go in (reasonable), only the bin package of
report-builder was installed (huh?), and wiki-publisher went in just
fine (will that even work in light of its hard dep on lo-java-common?).
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
installed packages are useless (lo-report-buildir-bin without
lo-report-builder?) or at worse broken.
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.
(Interestingly, libreoffice-script-provider-{bsh,js} depend on a JRE
_without_ depending on lo-java-common. Does that make sense?)
What I would like to see is for all the various LibreOffice packages
that can/must make use of Java to Depends:/Recommends:/Suggests:
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.
