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 <PLUGIN_FILE>'. > > 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 <PLUGIN_FILE>' 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 hp-plugin-installer. Why not just run hp-scan? > 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) Many users wear both hats. BTW, what is your HP device? Cheers, Brian..