On Thu, 06 Aug 2020 at 10:45:25 +0100, Jaime wrote:
> Question: what should I do?
In general, you should install recommended packages, which are recommended
for a reason. Remove or do not install *specific* recommended packages
if you have understood the implications of doing so and the functionality
you will lose. An interactive tool like aptitude might help with this.
> A recent change (1) to adwaita-icon-theme's debian/control.in altered
> adwaita-icon-theme's relationship with librsvg2-common from a
> "depends" to a "recommends".
This was done deliberately (not by me), to make it possible to have
basic GTK functionality on the architectures that do not have Rust
support. librsvg is now written in Rust, so we can either have GTK
uninstallable on such architectures, or GTK not able to render SVGs on
such architectures (or someone porting Rust to those architectures, but
that's not fast, and would have to be done one architecture at a time,
by someone who specifically cares about those architectures).
A third option would be for it to be a Depends on architectures that
are known to have Rust and a Recommends otherwise, but that would be an
inconsistency between architectures, and would also have to be kept in
sync with the list of architectures to which Rust has been ported.
If there is consensus that it is better for GTK to be uninstallable on
non-rusty architectures, or consensus that the SVG support should be a
hard dependency on rusty architectures, then that can happen. However, I
would want there to be a clear consensus on that, so that when the GNOME
team gets the inevitable bug reports about "GTK is not installable on
m68k" or "GTK is only installable on x86_64 if you also install librsvg",
we can point to that as the reason, and close them.
If there is no consensus, then it's the package's maintainers' decision
which to do.
> As a result, installing libgtk-3-0 with
> --no-install-recommends does not install librsvg2-common thus leaving
> libgtk-3-0 unable to render svg, which in turn causes all kinds of
> weird and wonderful rendering bugs.
If you don't install Recommends then you can expect severely degraded
functionality:
The Recommends field should list packages that would be found together
with this one in all but unusual installations.
— Debian Policy §7.2
If people want package maintainers to make the dependency graph more
flexible by reducing Depends to Recommends, then the price we have to pay
for that is that users who disable installation of Recommends need to be
prepared to accept a loss in functionality from doing so.
Otherwise, package maintainers will inflate weak dependencies from
Recommends back up to Depends, and instead of complaints about missing
functionality, we'll get complaints about "bloat" and inability to
install package X without closely related package Y.
We can't have it both ways: if Recommends are going to be useful, then
"most" users need to be installing "most" of the recommended packages.
smcv
