:: Re: [DNG] Broken Dependencies?
Top Pagina
Delete this message
Reply to this message
Auteur: Ken Dibble
Datum:  
Aan: dng
Onderwerp: Re: [DNG] Broken Dependencies?
On 10/4/24 04:55, Martin Steigerwald wrote:
> 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,


What am I trying to achieve?
I am of the opinion the less things one has, the less chance of one of
them breaking or causing problems.  I have been around long enough to
realize that the battle against clutter is never ending even if (or
because) I am occasionally neglectful. When I find an appropriate task
for a machine, I try to find a solution.  These solutions have
dependencies.  Sometimes later, I find a better or more appropriate
solution.  The earlier solution should be removed or else...clutter.

I have a firewall protecting the lan, I wasn't overally concerning about
the cups vulnerabilities.
The announcement did spark the thought process of having stuff that I
don't need installed, though.

As to the question of why a desktop on a server.  This habit/preference
goes back decades to when AlphaServer 8000's cost a million dollars,
were kept under lock and key, and even workstations cost tens of thousands.
I was given access to XWindows terminals to administer them.  Even
though the gui apps were simple under CDE, I found things like scroll
back buffers, xdiff, etc, very convenient and a major step up from
VT220s for administration purposes, especially for things that I saw
infrequently.

I still find gui apps simpler for a lot of tasks, especially since I am
old, do infrequent administration, and can't remember command line
options for a lot of things.

That aside some of the dependencies are just ridiculous.

acl
strongswan
unzip
wireguard
update-inetd
pipewire

Regards,
Ken