On Sun 30 Oct 2016 at 00:20:43 +0300, Reco wrote: > On Sat, 29 Oct 2016 20:36:27 +0100 > Brian <a...@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. > What do they give us in Debian instead? An enterprisey tangled mess. It certainly has complexity. > '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. > 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. I cannot see any PPDs in hplip-data: https://packages.debian.org/jessie/all/hplip-data/filelist Looks like a bug in the package description. > 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. > 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. > 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. > 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 Depends: would be unsuitable if you were only setting up a USB printer. > 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. > 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? > Things have improved somewhat since wheezy (they didn't provide > 'printer-driver-hpcups' back then), but it's only 'somewhat'. It was provided but under a different name. -- Brian.
