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!). 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
