Re: Re-enabling cups option in gtk3

[Greg Troxel <gdt%lexort.com@localhost>]

Martin Husemann <martin%duskware.de@localhost> writes:

> Can we please restart from scratch, as probably there is a lot of confusion
> and mixup of arguments.

One thing that seems clear is that there are people in multiple sets:

  people that think cups is ok and want to have it

  people that don't particularly want cups but think printing is broken
  in some apps if gtk3 doesn't have cups support

  people that really dislike cups

My read is that there are a significant number of people in each set,
and it's therefore not ok to discount any of them.


The "purity" point is that in pkgsrc, a number of packges install
programs with the same name as the base system, so that people who have
/usr/pkg/bin before /usr/bin in PATH -- which I think is the standard
approach -- get the pksgsrc versions instead.

This shadowing is helpful when one installs postfix, named, or openssl
from pkgsrc and intends for it to replace the base system functions,
(almost always because pkgsrc is newer).

It was sometimes helpful and sometimes not when heimdal is installed
that there was a /usr/pkg/bin/su that was ksu.  People living in full-on
kerberos world liked that, and it was troublesome for the other 99.9% of
thepeople that didn't try to install heimdal, but got it as a dependency
because some other program wanted to be able to support kerberos just in
case some user wanted to use it.

The heimdal experience points out that the concept of splitting
libs/support and client programs is useful, but also that it doesn't
tend to happen.

For cups, I see no problem with the libs being installed, and I don't
think it's a big deal that the server etc. is installed, as that doesn't
run and just wastes bits -- and anyone with firefox obviously has space
for a few more megabytes of wasted bits.

The real problem is installing these programs:

  /usr/pkg/bin/lp
  /usr/pkg/bin/lpq
  /usr/pkg/bin/lpr
  /usr/pkg/bin/lprm

because they cause a system with working printing via lpr to suddenly
try to print via cups, which 1) is not something the user asked for and
2) is almost certainly not going to work on a system where cups is not
configured.

I think regardless of other concerns, it's really not ok in general to
have programs that shadow base programs installed by a package that is a
dependency, rather than something the user explicitly asked for.

So, the question is how to make progress.  Looking at heimdal, there is
the kerberos-prefix-cmds option which defaults to on, and renames the su
built by heimdal to ksu (which was actually the traditional name in the
80s and 90s anyway).


If splitting cups really is too hard, I think it probably makes sense to
add a cups-prefix-cmds option to cups-base that results in the above 4
programs (and probably also lpoptions and lpstat) being installed as:

  /usr/pkg/bin/cupslp
  /usr/pkg/bin/cupslpq
  /usr/pkg/bin/cupslpr
  /usr/pkg/bin/cupslprm
  /usr/pkg/bin/cupslpoptions
  /usr/pkg/bin/cupslpstat

That will mean that people that want cups will have more trouble,
perhaps needs to add in symlinks (could be a cups-programs package, in
all seriousness) to make lpr be the cups lpr.   But it will prevent
people that aren't trying to use cups from having the cups lpr used.




I would also like to really understand the origin/reasons for the
problems with firefox when gtk3 is not built with cups, and why.  I have
gtk3 not built with cups currently (even though I have cups set up to
print), and I can report that firefox (the most recent version that
actually built on netbsd-8) pops up a print dialog that offers only
print-to-file.  I could guess about why, but I think it's bettter for
someone who really understands to explain, so that we can consider other
approaches to solving the user-facing pbrolem.

I'd also like to hear perspective from pkgsrc users on other than
NetBSD.