Re: Re-enabling cups option in gtk3

[maya%NetBSD.org@localhost]

On Sat, May 09, 2020 at 08:57:12AM -0400, Greg Troxel wrote:
> maya%NetBSD.org@localhost writes:
> 
> > (Gotta reply awkwardly, I don't subscribe to the mailing list...)
> >
> > On Sat, May 09, 2020 at 11:59:07AM +0200, Leonardo Taccari wrote:
> >> I would add a third reason (and I think that was also pointed out last
> >> time in <https://mail-index.NetBSD.org/tech-pkg/2018/06/29/msg019921.html>):
> >> 
> >>  - IMO a GUI toolkit should not force the user to install a print server
> >> 
> >> (...and at least last time I had checked it the `cups' option was
> >> disabled by default for all packages).
> >> 
> >> Also, why should it be enabled by default? (I think that it provides a
> >> more customized print "widget" when printing via, e.g.
> >> `gtk3-demo --run=printing' but this and previous discussion did not
> >> clearly mention that)
> >> 
> >> I would prefer that it is disabled by default for the 3rd reason.
> >
> > So, CUPS consists of two parts:
> > - The printing server
> > - libcups, and I assume GTK3 wants to use libcups to speak to CUPS.
> >
> > I could attempt to split CUPS into two parts, a very bare bones
> > no-server libcups and the server.
> > I don't know whether it'll win any minimalism contests, it probably
> > would still require as many dependencies.
> 
> I think the issue with cups as a dependency is not the weight, but that
> it installs server programs and particularly binaries like lpr that
> shadow base programs.  I think if the cups libraries are installed, but
> not the server pieces and especially not lpr, then there really is no
> problem.
> 

I'll be frank, with this being the condition for committing, I'd rather
throw the patch down the drain. I'm only dealing with CUPS as a favour
to someone else, and I don't want to implement leot's pet projects of
how GTK3 can be more minimal. I have my own todo items to worry about.