[OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain

[Michael Torrie]

Since Python 3's adoption is directly impacted by package managers and
curated repos (or lack thereof), I feel justified in continuing this
thread just a bit farther.

On 03/16/2015 04:02 PM, Chris Angelico wrote:
> It most assuredly does NOT suck for end users. Apart from issues of
> naming (grab "avconv" or "ffmpeg"?), it's easy - if someone needs to
> do audio manipulation, I can tell him/her to "sudo apt-get install
> sox" and that'll get the necessary program on any Debian-based distro,
> and likewise one command for any Red Hat distro. I'm not sure what you
> mean by "for developers" - do you mean that it's hard to package your
> software for each distro? Because the package manager benefits you
> even if you don't package your own program. Imagine you need a
> PostgreSQL database for your Python application - which also means you
> need psycopg2, of course. How do you go about writing installation
> instructions?

Except that it does suck in lots of ways.  I didn't say the Windows
method was better.  Certainly Poettering was not advocating for the
complete laissez faire crap shoot that is Windows software installation.
 Far from it.

But after 20 years, the package manager idea certain has revealed many
shortcomings (in short, it sucks in many ways).  Package managers work
great for setting up the core distro, and also if the packages you need
are in the repos.  Distros like RHEL and Debian tend to have long-term
stability at the expense of not having recent versions of programs and
libraries.

Although I will note that one major up and coming Linux distribution
eschews package managers completely.  That is ChromeOS, and it is
compelling enough that the CoreOS server container OS is based on it.
They threw out package managers entirely and use image snapshots and
diffs. (I'm not advocating that solution, but it is something people
have tried to get around package manager problems).

For developers things are even more grim.  Package managers certainly
don't work so well for third-party apps like VirtualBox, LibreOffice,
Firefox, etc.  Part of the issue is the multiple moving targets distros
present in terms of what's available in the system.  It's so bad in fact
that major projects that offer binary packages on their web sites end up
bundling copies of libraries they use, such as GTK, SSL, etc.   This is
how VirtualBox, Firefox, and LibreOffice all do it.  It works but it's
wasteful and they still have to target at least three to five different
distro/package manager combinations.

Ideally you should get your package in a mainline repo where ostensibly
it's updated and maintained and just works with your distro of choice.
Except when it doesn't.  As the prime example, take the OwnCloud, which
is, or was, in the official Ubuntu repos.  Do not use it! It's broken
and insecure, and no one is maintaining the package in the official
repos.  In fact OwnCloud.org asked Ubuntu to remove it entirely.  The
same thing has happened several times with Oracle Java and Ubuntu.
So we can't deny the curated package model does have issues and flaws.
PPAs address this for a fairly narrow audience (Ubuntu and derivatives
only).

This isn't saying that package managers don't work and don't have a
place.  They just have serious shortcomings that I believe are part of
what prevents major commercial players from even bothering to target
Linux (though the economics of software on Linux is probably the primary
reason).

> * LINUX: Red Hat-based *
> 1) As root, type: yum install postgresql python3-psycopg2
> 2) Install my program from blah blah blah

Yes that definitely works on Fedora more or less (if you're willing to
upgrade Fedora every year at least ensuring you have the latest and
greatest).  Step 2 is still a problem though.  Have to step outside the
package manager again.  Not ideal.

> (I don't have a Red Hat system handy to check, so the above examples
> might need to be tweaked. But you get the idea.)

Not merely tweaked.  It simply does not work on RHEL, any version.
Python3 can be installed from Software Collections (and that is somewhat
reasonable), but it won't integrate by default, so you can't use
#!/usr/bin/python3 in your apps by default without altering the system
paths.  Alternatively compile from source, but in many server rooms
that's strictly forbidden as it's not maintainable.

> Without actually going to any effort to build your own packages, you
> can still take advantage of one-command installation of all your
> dependencies. Without a package manager, you have to assemble them
> from all over the internet.

And again the ideas in the link I posted also enable all this and more,
and do it in a maintainable, logical way.  A natural extension of the
package manager.  I didn't expect anyone to actually read the post, as
interesting as it is, and thus I'm not disappointed that you dont' seem
to have read it.

> I call that a benefit :)

Yes, it is a benefit, but it also has serious drawbacks, with few easy
answers without making some major changes.

Will be interesting to see how it shakes out.  After 20 years I'm
certainly growing tired of how Linux software is distributed. I like
core stability, but I want to be able to use Python 3.5, or LibreOffice
4.3 (Linux Mint 17 does not have and will never have the latest
LibreOffice).  I don't want to have to upgrade my distro every six
months a la Fedora, and a true rolling distro just doesn't seem possible.