Re: [OT] Sorry state of hplip (was: [SOLVED] Re: [jessie] recording line-in using ALSA?)
Hi.
On Sun, Oct 30, 2016 at 05:15:51PM +0000, Brian wrote:
> On Sun 30 Oct 2016 at 18:24:50 +0300, Reco wrote:
>
> > Hi.
> >
> > On Sun, 30 Oct 2016 14:20:44 +0000
> > Brian <ad44@cityscape.co.uk> wrote:
> > >
> > > 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.
>
> If you have a problem you should seek help by starting another thread.
It works the way I've described, so why should I seek any help?
> > 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?
>
> People like GUIs; I believe system-config-printer and the CUPS web
> interface are popular for setting up printers. None of them are needed
> but they fulfill a need.
Please do not dodge the question. Why such GUI is needed for these
particular filters?
> > > 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?
>
> HPLIP does a bit more than handle printing.
And the reason to force this 'a bit more than printing' on all users
was?
> > > 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?
>
> Pass.
Can you agree that it's a bit unusual?
> > > 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'.
>
> I'm not getting into a comparison with every package of this nature in
> contrib.
Was not my intention.
> hp-plugin is not central to the function of suported hardware
> and HPLIP will work without it.
Yet the only function of the script is to provide user non-DFSG
compliant files.
> The script is a convenience one for the
> user and is not run from the maintainer scripts.
Other convenience scripts of similar nature get their own packages and
put into 'contrib'.
> > > Possibly needed for installing a plugin.
> >
> > A 'plugin' to what? Did you mean a 'non-free' blob maybe?
>
> I was using HPs terminology.
>
> > Does this 'plugin' gets installed every time someone prints?
>
> No.
Yet another reason to split it into a different package, don't you
agree?
> > > > 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's actually a very sound argument. Not wanting any of cups recommended
> packages is a respectable decision.
... and suddenly, by installing hplip, the user finally comes to their
senses, sees the light and installs avahi-daemon like it was intended
from the beginning. You're describing an artificial scenario.
> > It would be a valid argument *if* one could install HPLIP without CUPS,
> > but currently 'hplip' depends on 'cups', so that's impossible.
>
> True. But I think you do not understand what different purposes cups and
> HPLIP use avahi-daemon for. I didn't use "print queues" and "printers"
> as a matter of style.
Enlighten me, please. For what purpose HPLIP's backends use
avahi-daemon? Or maybe all those python scripts that are provided by
HPLIP?
> > > 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.
>
> Setting up a *non-shared* USB printer. Clearer?
Did I mention in my reply that your example was unclear somehow? Why
these childish appempts to offend me?
> Pass on the rest because packaging is not something I know much about,
> so I'm most likely to rely on the expertise of the maintainers. The
> changelog might give you some clue as to what is going on.
You could save us both time by providing this magical 'rely on the
expertise of the maintainers' advice from the beginning.
Reco
Reply to: