[conspire] People failing to learn about package gatekeeping, part 1

[Rick Moen]

Quoting Dire Red (deirdre at deirdre.net):

> I’m reminded of one job interview in my recent cycle where the work
> was largely API work (which didn’t sound particularly compelling to me
> before this, but definitely didn’t after): she (my interviewer) said
> that one of the frustrations of working in that group is that people
> would take 2-3 *years* to adopt even the biggest quality-of-life
> improvements, largely because of package interdependency requirements
> (especially with things like Node and PHP).
> 
> So instead took a position contracting for some “small” company and
> shipped a small app update the first week. Far more satisfying.

There are certainly troubling compromises that result from the (usual)
need to stay compatible with (invariably old to one degree or another)
packaged distro libs and other dependencies that some distro release
manager decided to be the "standard" supported version, maybe two years
ago.

So, developers want cutting-edge improvements available only with newer
version of everything, but those cannot easily be folded in without
chaos and instability.  Can't have everything.

IMO, software dependencies in Linux distros have, over the last decade,
become a complexity hairball, principally in DE-based desktop systems.
What was supposed to be a blessing, component software and shared libs,
has become a curse because the dependency tree makes distros brittle
and difficult to maintain.  

And the worst of that badness has been from the GNOME / freedesktop.org 
people.  Here are Debian's _direct_ dependencies for the GNOME Evolution
mail client.  https://packages.debian.org/bullseye/evolution
But that's just the tip of the iceberg:  The dependencies have
dependencies have dependencies have....

I really do understand the temptation to say "The hell with the distro's
choice of component versions.  I want the newest stuff."  And, what I'm 
saying is, there are ways for _experienced_ Linux users, if determined
to do that, to set that up without harming their systems, in a suitable
isolated subsystems, as long as they know they have implicitly agreed to
take on (for those subsystems) the responsiblities distro architects
and package maintainers normally do.  Users who aren't fully sure they
can handle that, shouldn't -- and maybe should switch to a "rolling" 
distro and live with the rough bits and inevitable problems.