Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
Hi Brian, Thanks for the pointer to the official site. Looks like the OpenPrinting mirror has been corrected by now. Is it normal that hp-plugin tries to download from OpenPrinting instead of the official site? On Tuesday, October 26, 2021 1:52:43 P.M. EDT Brian Potkin wrote: > You are are not the first (nor will you be the last) to have a problem > installing a plugin. This is upstream's responsibility. Oh I've no doubt I'm not the only one; that's why I'm thinking about how the whole situation might be improved. > > 1. Automatic updating of the plugin to the corresponding version - which, > > assuming an environment that uses one of the affected devices, is > > implicitly required by the hplip package for it to be at all useful. > > This is one of my sticking points. Automatic? A user has a device that > requires a non-free plugin for scanning. The user never scans, but is > still obliged to download and install it. Well, no, they wouldn't be. Regarding "automatic", I specifically mean for *updating* the plugin. Initially installing the plugin would still be a manual decision, in that the sysadmin (who, yes, might also be the user) would have to 'apt install hp-plugin-installer'. If they don't need it, they'd have no reason to install it in the first place. Nothing would depend on hp-plugin- installer, except that hplip *might* suggest it. (I thought I already said all that, but perhaps I was unclear.) This is how I'm thinking a hp-plugin-installer package will work: Importantly, it must pre-depend on the current hplip package. When the sysadmin installs it, its postinst script runs 'hp-plugin -i'. Sysadmin has to answer the two prompts to download and accept the license, which they would have to do anyway. Then in future when hplip packages receive an update, hp- plugin-install is also updated; its postinst gets triggered and runs the *updated* hp-plugin, which downloads the updated version of the plugin (with the usual prompts). The implication of this is that the sysadmin is always in control of the installation of the (updated) plugin, and the update always takes place at the same time as other package updates - the sysadmin doesn't have to remember to do it, or else be reminded at a random, possibly inopportune time. > > > There is also the matter of what runs the proposed package. It cannot > > > be from any of the HPLIP packages because, as the Debian Policy Manual > > > > > > says: > > > In addition, the packages in main must not require or recommend > > > a package outside of main for compilation or execution... > > > > hplip could suggest it, though. At any rate, I imagine the sysadmin would > > install hp-plugin-installer (from contrib) themselves. They would only > > need to do that once, and only if they actually had a device that needs > > the plugin to be installed. hp-plugin-installer would be versioned > > alongside hplip and update at the same time, and thereby run hp-plugin to > > grab and install the necessary plugin version at the time (or immediately > > after) the hplip update is installed. > > Any issues with hp-scan would be relected in hp-plugin-installer. Why > not just run hp-scan? I'm not sure why you brought up hp-scan. Did you mean hp-plugin? If that's what you meant, then yes, issues would be reflected, and that's part of the point. With 'hp-plugin-installer' as I propose, the sysadmin would be informed of a problem acquiring the necessary updated plugin, and can take action to correct that, all within moments of the hplip packages themselves being updated. At present, the problem might be hidden for however long until the user tries to print or scan, at which point corrective action by the sysadmin might be inconvenient or not immediately possible. > > > Ultimately, it is the user's responsibility to download a non-free > > > plugin. > > > > Well, to be precise, it's the sysadmin's responsibility to install said > > plugin, rather than the user's (unless they happen to be the sysadmin, but > > then it's a question of which hat they're wearing at any point in time) > > Many users wear both hats. Sure, but that doesn't invalidate my point. There's plenty of situations where it isn't the case - e.g., someone managing a system for a non-technically- literate relative or friend, or the admin of a school computer lab... > BTW, what is your HP device? Color LaserJet Pro MFP M277dw. Best, Brendon
Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
On Tue 26 Oct 2021 at 10:49:59 -0400, Brendon Higgins wrote: > Hi Brian, > > On Tuesday, October 26, 2021 8:13:01 A.M. EDT Brian Potkin wrote: > > On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote: > > > Hi Brian, > > > > > > Perhaps I was unclear in my description. You responded: > > > > You want to replace hp-plugin > > > > > > On the contrary, I would think the proposed hplip-plugin-installer package > > > would pre-depend on hplip and essentially just run hp-plugin in its > > > postinst. It's complementary, not a replacement. > > > > > > > with something Debian-specific that Debian has to maintain for ever. > > > > > > Debian-specific, perhaps, though hardly beyond ordinary packaging > > > practices. Could be useful for derivatives, too. I would think > > > maintenance for such a simple thing would be minimal (barring major > > > upstream changes - which users would have to figure out for themselves, > > > otherwise). > > > > > > And as I mentioned, there's plenty of precedent for this approach, and the > > > arguments against those are the same. > > > > It strikes me that an hplip-plugin-installer package would not provide > > anything over and above what hp-plugin provides. This checksum issue > > reported in Launchpad #1948555 is not uncommon and such a package > > would not alleviate it. The usual way to tackle it is download the > > plugin and install with 'sh '. > > Download the plugin from where? I traced its source to the location given in > that Launchpad bug, and it's obviously a broken upload at the server - this > is > a "true negative" checksum failure. (Please try it - it still hasn't been > fixed > as of writing.) I haven't been able to uncover an alternative download > location, so if you know of one I would love to hear it (really!). The official archive site is https://developers.hp.com/hp-linux-imaging-and-printing/plugins OpenPrinting provides a mirror as a service to users. A problem with it is a problem for OpenPrinting. 'sh ' is upstream's advice when hp-plugin doesn't behave. > This negative experience is what inspired me to suggest hp-plugin-installer - > because it does provide key usability benefits due to this property: it would > run at the same time that the hplip packages are updated. The benefits that > come from this are: You are are not the first (nor will you be the last) to have a problem installing a plugin. This is upstream's responsibility. > 1. Automatic updating of the plugin to the corresponding version - which, > assuming an environment that uses one of the affected devices, is implicitly > required by the hplip package for it to be at all useful. This is one of my sticking points. Automatic? A user has a device that requires a non-free plugin for scanning. The user never scans, but is still obliged to download and install it. > 2. Any failure to download/install the updated plugin can be found and > addressed by the system administrator immediately. This is in contrast to the > current situation where the system is left in an incomplete, unusable state, > for an indefinite period of time, until the user might try to use their > device, > encounter a problem, and the user (rather than system administrator) is > expected to fix that. > > In my case, the plugin file being broken upstream was my critical failure > point. I only encountered this weeks after the hplip packages updated - it > seems to me that the plugin file might have been okay back then. (I've since > had to downgrade back to stable's version.) But I can imagine other > situations > which would be helped by hp-plugin-installer, too - perhaps the system is > portable and not always connected to the internet, so downloading the plugin > at any given time (even if it is good upstream) is not feasible, but > downloading it when packages are also downloaded and installed makes much > more > sense. Or perhaps the user has been granted printing permissions but not root > permissions by the system administrator - the sysadmin would absolutely want > some kind of automation to install this plugin in such a situation... > > > There is also the matter of what runs the proposed package. It cannot > > be from any of the HPLIP packages because, as the Debian Policy Manual > > says: > > > > In addition, the packages in main must not require or recommend > > a package outside of main for compilation or execution... > > hplip could suggest it, though. At any rate, I imagine the sysadmin would > install hp-plugin-installer (from contrib) themselves. They would only need > to > do that once, and only if they actually had a device that needs the plugin to > be installed. hp-plugin-installer would be versioned alongside hplip and > update at the same time, and thereby run hp-plugin to grab and install the > necessary plugin version at the time (or immediately after) the hplip update > is installed. Any issues with hp-scan would be relected in
Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
Hi Brian, On Tuesday, October 26, 2021 8:13:01 A.M. EDT Brian Potkin wrote: > On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote: > > Hi Brian, > > > > Perhaps I was unclear in my description. You responded: > > > You want to replace hp-plugin > > > > On the contrary, I would think the proposed hplip-plugin-installer package > > would pre-depend on hplip and essentially just run hp-plugin in its > > postinst. It's complementary, not a replacement. > > > > > with something Debian-specific that Debian has to maintain for ever. > > > > Debian-specific, perhaps, though hardly beyond ordinary packaging > > practices. Could be useful for derivatives, too. I would think > > maintenance for such a simple thing would be minimal (barring major > > upstream changes - which users would have to figure out for themselves, > > otherwise). > > > > And as I mentioned, there's plenty of precedent for this approach, and the > > arguments against those are the same. > > It strikes me that an hplip-plugin-installer package would not provide > anything over and above what hp-plugin provides. This checksum issue > reported in Launchpad #1948555 is not uncommon and such a package > would not alleviate it. The usual way to tackle it is download the > plugin and install with 'sh '. Download the plugin from where? I traced its source to the location given in that Launchpad bug, and it's obviously a broken upload at the server - this is a "true negative" checksum failure. (Please try it - it still hasn't been fixed as of writing.) I haven't been able to uncover an alternative download location, so if you know of one I would love to hear it (really!). This negative experience is what inspired me to suggest hp-plugin-installer - because it does provide key usability benefits due to this property: it would run at the same time that the hplip packages are updated. The benefits that come from this are: 1. Automatic updating of the plugin to the corresponding version - which, assuming an environment that uses one of the affected devices, is implicitly required by the hplip package for it to be at all useful. 2. Any failure to download/install the updated plugin can be found and addressed by the system administrator immediately. This is in contrast to the current situation where the system is left in an incomplete, unusable state, for an indefinite period of time, until the user might try to use their device, encounter a problem, and the user (rather than system administrator) is expected to fix that. In my case, the plugin file being broken upstream was my critical failure point. I only encountered this weeks after the hplip packages updated - it seems to me that the plugin file might have been okay back then. (I've since had to downgrade back to stable's version.) But I can imagine other situations which would be helped by hp-plugin-installer, too - perhaps the system is portable and not always connected to the internet, so downloading the plugin at any given time (even if it is good upstream) is not feasible, but downloading it when packages are also downloaded and installed makes much more sense. Or perhaps the user has been granted printing permissions but not root permissions by the system administrator - the sysadmin would absolutely want some kind of automation to install this plugin in such a situation... > There is also the matter of what runs the proposed package. It cannot > be from any of the HPLIP packages because, as the Debian Policy Manual > says: > > In addition, the packages in main must not require or recommend > a package outside of main for compilation or execution... hplip could suggest it, though. At any rate, I imagine the sysadmin would install hp-plugin-installer (from contrib) themselves. They would only need to do that once, and only if they actually had a device that needs the plugin to be installed. hp-plugin-installer would be versioned alongside hplip and update at the same time, and thereby run hp-plugin to grab and install the necessary plugin version at the time (or immediately after) the hplip update is installed. When I get some time I'll try to get a basic patch working. > Ultimately, it is the user's responsibility to download a non-free plugin. Well, to be precise, it's the sysadmin's responsibility to install said plugin, rather than the user's (unless they happen to be the sysadmin, but then it's a question of which hat they're wearing at any point in time). Peace, Brendon
Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote: > Hi Brian, > > Perhaps I was unclear in my description. You responded: > > You want to replace hp-plugin > > On the contrary, I would think the proposed hplip-plugin-installer package > would pre-depend on hplip and essentially just run hp-plugin in its postinst. > It's complementary, not a replacement. > > > with something Debian-specific that Debian has to maintain for ever. > > Debian-specific, perhaps, though hardly beyond ordinary packaging practices. > Could be useful for derivatives, too. I would think maintenance for such a > simple thing would be minimal (barring major upstream changes - which users > would have to figure out for themselves, otherwise). > > And as I mentioned, there's plenty of precedent for this approach, and the > arguments against those are the same. It strikes me that an hplip-plugin-installer package would not provide anything over and above what hp-plugin provides. This checksum issue reported in Launchpad #1948555 is not uncommon and such a package would not alleviate it. The usual way to tackle it is download the plugin and install with 'sh '. There is also the matter of what runs the proposed package. It cannot be from any of the HPLIP packages because, as the Debian Policy Manual says: In addition, the packages in main must not require or recommend a package outside of main for compilation or execution... Ultimately, it is the user's responsibility to download a non-free plugin. Cheers, Brian.
Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)
Hi Brian, Perhaps I was unclear in my description. You responded: > You want to replace hp-plugin On the contrary, I would think the proposed hplip-plugin-installer package would pre-depend on hplip and essentially just run hp-plugin in its postinst. It's complementary, not a replacement. > with something Debian-specific that Debian has to maintain for ever. Debian-specific, perhaps, though hardly beyond ordinary packaging practices. Could be useful for derivatives, too. I would think maintenance for such a simple thing would be minimal (barring major upstream changes - which users would have to figure out for themselves, otherwise). And as I mentioned, there's plenty of precedent for this approach, and the arguments against those are the same. > Patches are welome Cool! Willing to have a go. Where should I start? Best, Brendon
Bug#997795: hplip: Make a hplip-plugin-installer package
Source: hplip Severity: wishlist X-Debbugs-Cc: bren...@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