Bug#997795: closed by Brian Potkin <claremont102@gmail.com> (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 <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..
Reply to: