Lähettäjä: Steve Litt Päiväys: Vastaanottaja: linux-il Kopio: tech, dng Aihe: Re: [DNG] dependency hell OR it should not be this hard
On Sun, 11 Aug 2019 09:05:24 +0300
Shlomo Solomon <shlomo.solomon@???> wrote:
> Let me start by saying that I'm not looking for a solution - I solved
> my problem. I'm just angry and letting off some steam.
[snip successful attempts using a ~10 step apt/dpkg witch's brew]
I feel your pain. Probably we all do.
And it's likely the better people to let off steam at would be:
1) The maintainers of your distro
2) The maintainers of your "Desktop Environment", if any
3) The authors of the software concerned
DISTRO:
Your complaint isn't very detailed, but the fact that you needed apt to
fix it suggests you're using a Debian derived distro. Most Debian
extension distros, such as Ubuntu, Mint and Knoppix, add hypercomplexity
in order to make them more magically "we do it all for you" and "user
friendly", or just to make things look pretty.
Debian itself, once a simplistic distro, has been slowly complexifying
itself, first by defaulting to selecting of that ball of
confusion Gnome3, which itself has been complexifying at a remarkable
rate, and then by pledging allegiance to systemd: The ultimate ball of
confusion.
About the only apt packaged distro I could recommend today, from a
dependency-sanity point of view, would be Devuan, which rejected
both Gnome3 and systemd.
I find it amusing that Debian's solution to substituting a non-systemd
init system involves a many-step raindance where you pin this package
and hold back that package.
Of course, Redhat and Redhat-derived distros are worse.
Tell your distro maintainers to quit making package recommends into
hard requirements, and to find better solutions than secret apt meetings
with secret dpkg handshakes, or else consider not packaging it at all.
There are usually substitutes and equivalents.
DESKTOP ENVIRONMENTS:
Desktop environments, which bind a window manager and a bunch of
applications together, including all sorts of interdependencies and
promiscuous communications inside and outside of dbus, were obviously a
bad idea from the beginning, for people who want to control their
computers rather than the other way around.
If you use a desktop environment, write to them and tell them to reduce
promiscuous communication and dependencies. They'll laugh at you, of
course: Their purpose on this earth is to create obscenely
interdependent black boxes.
You can avoid a lot of this by going back to a window manager and
selecting your applications a-la-carte, trying mightily not to include
desktop environment apps. If enough people were to do this (not very
likely, most people are wedded to their "we do it all for you"
environments), the "desktop environments" might catch on and put more
of a priority on modularity and thin interfaces (or no interfaces where
not needed).
I kicked KDE and every KDE app and library off my computer in 2012-2013,
and lived to tell about it. I've never used Gnome3, and slowly but
surely I've been kicking its apps and libraries off my computer. Now I
boss my computer around, not the other way around.
THE SOFTWARE AUTHORS:
True story. When using Python writing a piece of free software intended
to be used by others, I needed one minor but not obvious how to code
functionality. So I asked how to code it on the Python IRC channel. Not
one answer, but three or four people told me to use some ginormous
library, itself having lots of dependencies, that was not part of the
standard Python distribution.
I explained that I didn't need all that stuff, I just needed this one
functionality. I didn't want my users to have to integrate this library
into their systems. "No problem", one of the IRC denizens proclaimed,
"that's what the Python <whatever> is for: You can build your own Python
interpreter for your one application, and ship the interpreter along
with the app". Look at your computer's clock: This is not an April Fools
joke, this happened.
If course I said "no", and then the real abuse happened, with the usual
"don't reinvent the wheel" and "scared to learn new things" and a new
creative diss: "Real programmers try new packages just to get familiar
with them, it's a real opportunity!"
Unfortunately, these guys weren't unusual. Way too many programmers, in
the name of avoiding reinventing the wheel, integrate somebody else's
wheel, when all they needed was an easily available single spoke. You
know who suffers? The distro maintainers and the users.
All too many developers put absolutely zero priority on simplicity. The
slightest improvement in "pretty", or the slightest "improvement" to
keep the user from having to use a text editor, is perfect
justification to bring in a gargantuan software library with poorly
documented API, lots of child dependencies, grandchild dependencies,
and who knows how far down the tree it goes. And at any given time,
at least one dependency of that software dependency tree gets buggy or
goes unmaintained or sets a dependency on something so modern it won't
work with your distro, and you get to use a 10 step apt/dpkg
choreography.
Tell the software authors your objections to gratuitous dependency
inclusions, as well as unnecessary and unhelpful communications with
barely related software. Tell them you choose software to work and keep
on working, not to be pretty or spare you from using an editor.
And then do what you told them: When evaluating free software
alternatives, significantly downvote those with too many, or
unnecessary, dependencies. And if the simpler software lacks a feature
you need, you can usually kludge it together with a couple shellscripts
and maybe some Python/Perl/Ruby/Lua/awk/grep/sed. We all hate to
kludge, but I think the ultimate kludge is some conceited developer
requiring 100K lines of imported code to give a couple features he could
have done in 100 lines of self-written code, if he'd bothered.
I copied the GoLUG mailing list because it's my home-town LUG, and the
Devuan mailing list because they're the one direct Debian fork
that eschews unnecessary dependencies and intermodular communications.
Notice that some forks and extensions of Devuan also keep complexity to
a minimum.