Re: Re-enabling cups option in gtk3

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

David Brownlee <abs%absd.org@localhost> writes:

> On Mon, 11 May 2020 at 13:16, Greg Troxel <gdt%lexort.com@localhost> wrote:
>>
>> 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).
>
> Could this be managed by extending pkg_alternatives to support
> symlinking to base binaries?
>
> That would allow the same binary cups package to work for people who
> want $PREFIX/bin/lpr and friends to be cups or default OS versions...

I suppose it could be used.

I think the only hard requirement is that if someone has cups installed
as a dependency instead of intentionally, then the base lp/lpq/lpr/lprm
may not be shadowed.

I was thinking of a "cups-clients" package which just contains 4
symlinks from /usr/pkg/bin/lpr to /sur/pkg/bin/cupslpr and so on, which
Is sort of alternatives-like.

The hard work is changing cups-base, and ensuring there are no other
problems.  I received a report in private mail that someone had their
/etc/printcap destroyed when uninentionally installing cups, and I'm not
sure if one needs to run something on purpose for that to happen (would
guess so).  I know cupsd does overwrite /etc/printcap.