[GTALUG] updates and shared libraries [was Re: A find alternative: fselect]

[D. Hugh Redelmeier]

TL;DR: managing package change: in distro or around distro

I've written a long message because I think that this is one of the
key tensions in the Linux world.  I'd like to understand the solution
space better.

| From: o1bigtenor via talk <talk at gtalug.org>

| Given what you have described I'm wondering if 'Go' functions
| similarly

I believe go is statically linked.  But I don't know that for sure.  I
haven't yet programmed in go.

| - - - and then maybe that is why LXD is currently only supported
| when its installed using Snapd and the miasma forces updating - - -
| no matter what (max 2 months).

I don't remember what distro you are using.

If I remember correctly, LXD is part of the Canonical world.  So is
snapd.  It would seem to be on-brand to distribute LXD as a snapd.
(My impression is that Canonical has trouble sharing with others.
After a few failures (Unity, Upstart, ...), they kind of get that
sharing is needed for success.)

================

The conventional linux model is that distros deliver a curated
collection of packages.  They also mediate updates.

You pick your distro based on how much you like their selecting,
testing, and updating of their collection.

That's a pretty course knob to adjust.  Stable distros typically are
slow to adopt some upstream improvements.  RHEL is *really* slow but
*really* reliable and stable.  Red Hat puts a whole lot of effort into
backporting and validating fixes (as opposed to improvements).  This
is often without "upstream" segregating such changes.  That's where
they really earn their fees.

Fedora, on the other hand, mostly tracks upstreams (with some
checking).  That means tremendous package churn.  Not recommended for
production use.

I haven't seen Ubuntu's principles clearly and precisely enunciated.
But LTS seems to be like CentOS, but not as stern.  Non-LTS is like
Fedora, but mostly staying with upstream-as-of-release freeze.

Ubuntu seems to do much less engineering but has done a good job
within that constraint.  Of course lots of that engineering is really
done by debian.

| I don't check weekly for system updates here but I do try to keep my
| systems updated for security reasons but I am very very uncomfortable
| when the right to control the timing of the updating is taken from me.

If your machine is connected to the internet, especially if it offers
services to the internet, you probably need to be able to do certain
updates very quickly.  When a fix comes out, exploitations may follow
within hours.  Typically distros make the update available when or
before the vulnerability disclosure is published (it is hoped that
this reduces the vulnerability window).  So you may want security
updates applied ASAP, perhaps through automation.

Note: you may find out when your security is compromised but you may
not.  So saying "it has never been a problem for me" is naive.

================

I am a contributor to the Libreswan ipsec implementation for Linux.
RHEL and Fedora include Libreswan.

We have one development tree.  Security fixes, bug fixes, and feature
changes are all piled in.  It's hard work for Red Hat to separate the
fixes from the feature changes and then backport the fixes.  debian
does a bit of that too (I'm not sure how much).  I don't know of any
other distro doing that with Libreswan.

================

If you remember, we were invited to a recent debian bug squashing
party.  I attended.

The purpose was to remove release-blocker bugs from packages.

I picked the poppler package to work on.  There were a number of CVEs,
some considered release blockers.  Naively, I would have considered
all CVEs to be release blockers, but that wasn't the case.

All the CVEs were fixed in newer versions of poppler.  But since
debian had frozen the packages for release, we could not just adopt
the newest version of poppler.  Instead, we had to import each
changeset that fixed a blocking CVE and backport it to the frozen
version of poppler.  The logistical friction was considerable.  I
didn't manage to actually accomplish anything in the day.

It is very important for a distro to get the process right.  The
application of process, on a micro scale may look silly, but the
discipline surely makes for more predictable and consistent results.

================

distros have been struggling with a few problems:

- some customers want stability EXCEPT for a few things key that are
  critical to their use.  For example, they might wish a current PHP.

- it is a lot of work for a project to get their package adopted by
  all the distros that they care about.  As a user, you may find that
  a package has not been ported to your distro of choice.

- some organization might wish to deploy a package of their own
  creation internally, on several different distros.

Snaps, flatpaks, and containers are all attempts to address these (and
other problems).

Example: I recently wanted Gargoyle (interactive fiction player) on
Fedora.  The .rpm didn't work (the wrong name for a shared library).
So I had to figure out how to build it from the git tree.  If they had
provided a flatpak, I would not have had to do that.