--- Begin Message ---
Source: hplip
Severity: wishlist
X-Debbugs-Cc: brendon@quantumfurball.net
Dear Maintainer,
As I understand it, licensing restrictions mean that the HP plugin, necessary
for some printers/scanners (including the MFC I own), cannot be packaged in the
ordinary Debian way. Instead, currently, if the Debian hplip packages receive
an update, the next time a user attempts to use their printer/scanner they are
interrupted until they download and install the latest plugin.
This ends up being a nuisance manual process which is asynchronous with the
actual change that made it necessary (the package update). Moreover, such an
action (choosing to install the plugin package) is arguably not appropriate for
the user role, anyway - rather, it is a system administrator question (for
which the user may not actually have permission to decide). (It doesn't help
that the download is a single point of failure that can be triggered at this
later time; see https://bugs.launchpad.net/hplip/+bug/1948555 ...)
Why not create a hplip-plugin-installer package (contrib), version-matched to
the other hplip packages, which downloads and installs the HP plugin in its
postinst? It would solve the primary issue, taking place at the same time as
the other hplip packages are updated (and therefore could fail, and be
corrected or reverted, all at that time). As a bonus, it would automate most of
that nuisance process while allowing the system administrator (rather than
random user) to accept (or decline) the installation.
Lots of precedent exists for such a package. A cursory search through the
contrib section for "download" in the package description brings up many, with
notable examples being ttf-mscorefonts-installer, google-android-ndk-installer
(and family), the historical (now-defunct) flashplugin-nonfree, and a swarth of
firmware blobs.
I'm broadly familiar with the Debian packaging process, but not all of the
details. Nevertheless, I am technically inclined, and for how many times this
nuisance has bitten me I'm willing to help make this suggestion happen however
I can.
Best,
Brendon
-- Package-specific info:
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (100, 'experimental-debug'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.14.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
--- End Message ---
--- Begin Message ---
On Sun 24 Oct 2021 at 11:13:40 -0400, Brendon Higgins wrote:
> Source: hplip
> Severity: wishlist
> X-Debbugs-Cc: brendon@quantumfurball.net
>
> Dear Maintainer,
>
> As I understand it, licensing restrictions mean that the HP plugin, necessary
> for some printers/scanners (including the MFC I own), cannot be packaged in the
> ordinary Debian way. Instead, currently, if the Debian hplip packages receive
> an update, the next time a user attempts to use their printer/scanner they are
> interrupted until they download and install the latest plugin.
>
> This ends up being a nuisance manual process which is asynchronous with the
> actual change that made it necessary (the package update). Moreover, such an
> action (choosing to install the plugin package) is arguably not appropriate for
> the user role, anyway - rather, it is a system administrator question (for
> which the user may not actually have permission to decide). (It doesn't help
> that the download is a single point of failure that can be triggered at this
> later time; see https://bugs.launchpad.net/hplip/+bug/1948555 ...)
>
> Why not create a hplip-plugin-installer package (contrib), version-matched to
> the other hplip packages, which downloads and installs the HP plugin in its
> postinst? It would solve the primary issue, taking place at the same time as
> the other hplip packages are updated (and therefore could fail, and be
> corrected or reverted, all at that time). As a bonus, it would automate most of
> that nuisance process while allowing the system administrator (rather than
> random user) to accept (or decline) the installation.
>
> Lots of precedent exists for such a package. A cursory search through the
> contrib section for "download" in the package description brings up many, with
> notable examples being ttf-mscorefonts-installer, google-android-ndk-installer
> (and family), the historical (now-defunct) flashplugin-nonfree, and a swarth of
> firmware blobs.
>
> I'm broadly familiar with the Debian packaging process, but not all of the
> details. Nevertheless, I am technically inclined, and for how many times this
> nuisance has bitten me I'm willing to help make this suggestion happen however
> I can.
You want to replace hp-plugin with something Debian-specific that
Debian has to maintain for ever. Patches are welome but, until they
arrive, I am closing this report.
Cheers,
Brian.
--- End Message ---