Hi Ken.

Ken Dibble - 03.10.24, 21:14:37 CEST:
> Thought I would try to clean up things that aren't being used on a
> server.
>
> The server does have a graphical login and desktop available for
> convenience.
>
> It has no printer and anything that needs to be printed can be printed
> from a workstation.
>
> Apparently a bad idea.
[…]
> sudo apt remove libcups2
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done

Well, what did you expect?

Many desktop packages depend on libcups2.

My servers do not have libcups2 installed… but they do not have a desktop
for convenience either. A server, especially when it is accessible from
the Internet should not have a desktop IMHO. For a local network server…
it is more tolerable, but I do not see why… it makes updates for time
consuming and complex. I already have enough work to do to maintain my
laptops which all have Plasma desktops.

I am not sure whether the recommendation the *.so file(s) for it out of the
way is such a good idea. Why? If Linux executable loader does not find a
library an executable depends on… usually it does not start the
executable. You can see the error message when trying to run it from a
shell. Which means that parts of your desktop probably would not run
anymore.

May I ask: For what purpose you like to remove libcups? What is it you
like to achieve with that?

If its about the CUPS related security issues discussed here previously,
installing updates for CUPS related packages should be enough by now.
Additionally I'd remove cups-browsed package in case you do not need its
functionality for extra safety.

Really I got the impression that with other approaches you are likely to
needlessly generate trouble for yourself :)

Another approach would be to see whether Alpine has fewer CUPS related
dependencies on desktop packages… but I am not sure they would, cause
actually it is expected that desktop applications can print. And with the
dynamic linking approach on Linux those shared object files usually need to
be accessible. On AmigaOS applications specifically opened native AmigaOS
libraries. And they could react to a failure in opening a library. Thus
they could dynamically disable functionality provided by that library. But
the AmigaOS based library approach had other disadvantages.

Best,
--
Martin