#1149892 Installing libreoffice-writer does not install correct gtk/qt theme and other dependencies

Package:
libreoffice-writer
Source:
libreoffice-writer
Description:
office productivity suite -- word processor
Submitter:
Date:
2026-10-05 04:53:02 UTC
Severity:
normal
Tags:
#1149892#5
Date:
2026-10-03 22:18:24 UTC
From:
To:
Installing libreoffice-writer, libreoffice-calc, libreoffice-impress and
other app subpackages without the main "libreoffice" package results in a
bad gtk/qt theming (because there is no libreoffice-gnome/libreoffice-plasma
dependency), missing language translations (no libreoffice-l10n dependency),
missing hunspell/myspell dictionaries (no hunspell-*/myspell-* dependency)
and other missing things. Please consider fixing this. Not every user wants
to install full LibreOffice suite, but users still expect the installed apps
to work correctly. Also, the apps themselves do have AppStream metadata and
show in GUI software stores (GNOME Software, KDE Discover), the main
libreoffice package does not.
#1149892#10
Date:
2026-10-03 22:52:35 UTC
From:
To:
If this gets fixed, please consider backporting the fix to Trixie. Thanks!
#1149892#15
Date:
2026-10-04 02:02:47 UTC
From:
To:
severity 1149892 wishlist

tag 1149892 + wontfix

thanks


Am 04.10.26 um 00:18 schrieb asciiwolf@seznam.cz:

This would mean installing all of  them even if only one wants writer or calc or whatever. Even if it's not needed (Qt on GNOME desktops, vice versa, unneeded languages ..)

Basicallwhat you want is one package containing it all.

There is a reason this isn't done (people do wwant stuff alone, don't need Java dependencies or other heavy dependencies, etc.)


This is a deliberate decision-.
For people who don't know the libreoffice metapackage exists. For people who do know they can install the subpackages and install stuff needed. (Or use the tasks which *do* install the correct Gtk/GNOMME themeing)

Of course, because the metainfo is app-specific. (e.g. /usr/share/metainfo/libreoffice-writer.appdata.xml, so they *do* belong into the app subpackages), not a generic file.


Sorry, there is nothing to fix here. At all.


Later you write:

 > If this gets fixed, please consider backporting the fix to Trixie. Thanks!

It won't. Besides that it won't be fixed a big change like this never will be backported to official trixie.

Regards,


Rene
#1149892#24
Date:
2026-10-05 00:18:34 UTC
From:
To:
Great, so you rather let users end up installing half-broken apps if they install the app subpackages and not the main package (that is not even possible to install using AppStream-based GUIs). *sigh*
#1149892#29
Date:
2026-10-05 04:50:37 UTC
From:
To:
Am 05.10.26 um 02:18 schrieb asciiwolf@seznam.cz:

You didn't even answer on the technical part. There is no way you can get what you want without having that (or making -writer etc) depend on all VCL plugins.


I would - as said - rather have proper packages without forcing everythihing (including Gtl3 *and Qt *and* KDE *and Java and whatever) on everyone.

(For Gtk3/Qt etc. upstream "solves" that by ignoring the dependency and hoping the linkage will work in in the installed system because the libs will be there.

Which of course will fail if one (as now in sid) uses stuff only in Qt 6.11 for example. Debian policy correctly wants full, correct library dependendency.

If I did this (and for your trixie question: that would be a too big change for trixie)  people will correctly complain either way.


And for languages/dicts: (For) watever language? Which one? All? All the big help? All dicts?


There's no way to do this without having a big fat(tm) package.
Those AppStream based GUIs are a problem, yes.  Breaking the package is not the solution, though.


Regards,


Rene