On Sat, 18 Apr 2020 at 00:10:16 +0800, Drew Parsons wrote:
> The problem arises from some 3rd party sources providing deb packages
> that users might reasonably want to use,
> - google-talkplugin for accessing Google Hangouts on firefox
> - flashplugin-nonfree for managing Adobe flash plugin.
> (admittedly the latter is in Debian contrib, we can fix it ourselves)
> There's also dropbox, not that I'd recommend people to use dropbox but
> sometimes they don't have a choice.
Minecraft is another proprietary package with the same issue: #956520
(which also mentions dropbox).
For context, libpango1.0-0 became transitional in 2013. The maintainers of
these packages have had just over 7 years to update them: even for Debian,
that's 3½ release cycles, and we normally remove transitional packages
after a single release cycle. (#940744 was the bug report pointing out
that this one was overdue for removal.)
google-talkplugin didn't seem to be necessary last time I used Hangouts;
browsers have dropped NPAPI support and Google seem to be increasingly
pushing users towards Chrome/Chromium, so I suspect its days are numbered.
flashplugin-nonfree doesn't seem to have worked correctly since 2017, the
plugin it installs is full of known security vulnerabilities, and, again,
browsers have dropped NPAPI support, so I can't say I feel particularly
guilty about breaking that one.
> The problem is the tight version dependency in libpango1.0-0,
> Depends: libpango-1.0-0 (= 1.42.4-8)
It's certainly part of the problem, and if we bring back libpango1.0-0,
relaxing the lockstep dependencies to be (>=) is a good idea: that will
allow users of the last release that has it (presumably Debian 11 and
Ubuntu 20.04) to keep it installed even after they upgrade to the next
stable release (let's assume Debian 12 and Ubuntu 22.04).
However, users of Debian 12 and Ubuntu 22.04 who did not already have
those third-party packages installed will not be able to install them,
unless they add by-then-obsolete releases to sources.list in order to
exhume an old version of libpango1.0-0. So my concern is that on the
next attempt to remove libpango1.0-0, we'll get bug reports demanding
that we bring it back again for the benefit of proprietary third-party
packages, and so on, forever.
Carrying around historical baggage forever wouldn't be *so* bad, except
for the existence of libpangox...
> libpangox-1.0-0 (>= 1.44.7-3)
Actually, that version number needs to be 0.0.2.
The more major problem with libpango1.0-0 is that it pulls in the Core
X backend, libpangox-1.0-0, which was historically part of pango1.0
but is now built from a separate source package (hence the much lower
version number). It's unmaintained upstream, no longer exists in Ubuntu's
second-class-citizen i386 architecture (#948462), is currently RC-buggy
because it fails to build from source against pango 1.44, and should
really get removed from Debian at some point soon.
But, libpango1.0-0 historically provided the Core X backend, so not having
a hard dependency on libpangox-1.0-0 is a functional regression... and
the proprietary packages that still depend on libpango1.0-0 might be
sufficiently ancient to be using the Core X backend? (I have no idea,
to be honest.)
One possibility is to bring back the transitional package for one more
release cycle (ugh), give it (>=) rather than (=) dependencies on libraries
from the same source package like you suggested, but downgrade the Depends
on libpangox-1.0-0 to Recommends or Suggests? That's not *strictly* correct,
but maybe close enough?
I'm fairly sure that what Ubuntu have done for now (libpango-1.0-0 Provides
libpango1.0-0) is not correct, because third-party proprietary binaries
might not be using the ancient Core X backend, but they probably *are*
using libpangocairo, libpangoxft or libpangoft2.
smcv
