Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)
Hi.
On Sun, 30 Oct 2016 14:20:44 +0000
Brian <ad44@cityscape.co.uk> wrote:
> On Sun 30 Oct 2016 at 00:20:43 +0300, Reco wrote:
>
> > On Sat, 29 Oct 2016 20:36:27 +0100
> > Brian <ad44@cityscape.co.uk> wrote:
> >
> > > On Sat 29 Oct 2016 at 21:51:48 +0300, Reco wrote:
> > >
> > > > Oh, and don't get me started on the way they package hplip.
> > >
> > > Please do. What is wrong with the packaging of hplip?
> >
> > I won't speak of stretch and sid, as these branches of Debian
> > distribution don't interest me in this regard so far.
> >
> > The task itself is simple - one (may be two for the redundancy)
> > centralized print-servers with arbitrary number of clients (without
> > any CUPS or HPLIP). Several HP printers, because they bought the stuff.
> >
> > What's needed? A small amount of packages providing needed CUPS
> > filters, backends and PPDs. The CUPS itself, of course.
>
> printer-driver-hpcups and printer-driver-hpijs would be sufficient for
> just printing. That is why the packages are provided.
'Should be' does not equal 'actually working' in this case.
> > 'hplip' itself, and it's direct dependencies 'hplip-data' and
> > 'printer-driver-hpcups'.
> >
> > There's also 'hplip-gui' with the bunch of worthless (for the
> > print-server) GUI tools. Oh, and python-qt4 as a dependency and a half
> > of KDE with it as a result, not a small achievement for the package of
> > the size of 88k.
>
> Upstream doesn't provide a GTK GUI; the packager doesn't have any
> option. The package is also optional to install; a user's choice.
You're missing the point. What's the reason to provide a GUI to a bunch
of CUPS filters in the first place? Why such GUI is needed for these
particular filters, but not CUPS itself?
> > Let's continue with 'hplip-data' as its list of dependencies is smaller.
> > For the lazy of us, package description states 'This package
> > contains data files and PPDs for the HP Linux Printing and Imaging
> > System'. Apparently said 'data files' are in fact python scripts put
> > into this package for some bizarre reason, as package brings you python
> > installation immediately.
>
> The "bizarre reason" reason is probably that the .py and .pyc files are
> platform independent.
And the reason to put all those unrelated to actual printing files into
the package was?
> > Next, the big winner, 'hplip'. Highlight points include:
> >
> > 1) Python as a dependency, again. Wait, haven't we install one already
> > with 'hplip-data'? Some python modules too, yet the package does not
> > contain a single python script (see pt 6).
>
> See above.
Nope, does not cut it. A package does not provide anything written in
python by itself. Why does it depends on python then?
> > 2) wget as a dependency. Included for the sole purpose of acquiring
> > non-free blobs from openprining.org by /usr/bin/hp-firmware (see pt 6),
> > yet the package somehow belongs in 'main'.
>
> main's ok. No non-free blobs are packaged.
b43-fwcutter, flashplugin-nonfree or ttf-mscorefonts-installer (to name
a few) do not package blobs either, they *only* download and/or
process them. Yet all such things reside in 'contrib', not 'main'.
> > 3) policykit-1 as a dependency. How exactly it's required for the
> > actual printing done by CUPS invoking HPLIP filters
> > (executables /usr/lib/cups/filter/) and backends
> > (executables /usr/lib/cups/backend/)?
> > Hint - it's not. But a certain python script (see pt 6) apparently
> > does.
>
> Possibly needed for installing a plugin.
A 'plugin' to what? Did you mean a 'non-free' blob maybe?
Does this 'plugin' gets installed every time someone prints?
> > 4) avahi-daemon as Recommends. Apparently it's considered so important
> > that they recommend it again (CUPS has the same Recommend). Kind of
> > surprised not to see it as Depends.
>
> CUPS was installed without its Recommends: because you do not want to
> discover Bonjour broadcasted print queues. Later, HPLIP was installed
> and you want to discover Bonjour broadcasted HP printers.
A weak argument as no other printer driver has this ridiculous
Recommends. One for the CUPS (where it serves its purpose indeed) is
enough.
It would be a valid argument *if* one could install HPLIP without CUPS,
but currently 'hplip' depends on 'cups', so that's impossible.
> A Depends:
> would be unsuitable if you were only setting up a USB printer.
First, that logic did not stop them from forcing one to install a
PolicyKit, for instance.
Second, said USB printer can be shared over the network by CUPS, so
such dependency is actually justifiable.
> > 5) Aforementioned backends. Worth mentioning as another part of the
> > puzzle actually related to the printing (filters) resides in
> > 'printer-driver-hpcups' (which is by itself is ok). Apparently because
> > reasons.
>
> Sorry; don't follow.
What's the reason that two actually useful package parts ended up in two
separate packages, and one of them provides 'everything and a kitchen
sink'?
> > 6) A bunch of symlinks to assorted python scripts from 'hplip-data',
> > note again that it's 'hplip' that contains all those python script
> > dependencies, not 'hplip-data'.
>
> Platform independence again?
There's package that provides a bunch of python scrips, yet the package
depends on python only. That's 'hplip-data'.
There's package, that provides symlinks, yet the package depends on
python and a load of python modules. That's 'hplip'.
Are you still not seeing anything wrong here?
So, let me reiterate. HP provides a couple of useful files (backends,
filters), lcl and ldl 'sources' (generating PPDs in runtime has never
been more fun!), bundled with all kinds of python scripts, which usage
is situational at best. Why? Because enterprisey.
What Debian does? Instead of splitting useful parts into one package,
and useless ones into another - they give us the same mess HP provides.
Reco
Reply to: