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
