[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#997795: hplip: Make a hplip-plugin-installer package



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


Reply to: