When stability is pointless

[Mark Haney]

Sam Kuper wrote:



> Stability
> ---------
> 
> Package managers facilitate stability. Given the foregoing, this
> should come as no surprise. Yet in the context of many Linux
> distributions, stability means something more specific than the
> colloquial "reliable, consistent" sort of meaning that the term
> normally implies. Stability, in the context of these distributions,
> means "unchanging, except with regard to security". One such
> distribution is Debian.

Stability is NEVER pointless.  However, it /can/ be used as an excuse to 
leave a newer package as 'testing' due to the fact that 'if it isn't 
broke, don't fix it'.  If a newer version of a package provides trivial 
changes, /or/ changes that have the potential for security breaches, 
then that's a good reason to have the 'latest and greatest'.

Stability in the Debian world (IMHO) tends to mean exactly what you 
describe.  At least the previous versions from the one due to be 
released.  It was (and is) impossible to maintain and older Debian OS 
because of the lack of any method where honest to goodness 'stable' 
packages get moved from the 'testing' repo to the stable one.  It became 
customary to simply enable the testing repos and be done with it.  But 
that's not the case with fedora (for example) because it truly is as 
bleeding edge as you can get without spending all day/every day finding 
and downloading/compiling the latest of everything.  In most cases (but 
not all admittedly) the fedora packages are 'stable' and work well out 
of the box.


> 
> Through the magic of package managers, Debian maintainers maintain
> multiple packages of each original software item they want to make
> available to users. The reason for the multiple packages is normally
> to achieve stability. The stability is achieved by packaging a version
> of the original software that has been tested sufficiently to warrant
> confidence in its security: it is not known to compromise systems on
> which it runs (except in cases where it may do so by explicit design).
> This "stable" package is then offered to users for, typcially, many
> years, and is not altered in any way except if a security flaw is
> discovered in it. Only if a security is found will the package be
> modified: to patch the flaw.

Yes, this is true (or was) in the Debian world, but remember, there are 
other distros and package managers.

> 
> Meanwhile, the maintainer will keep an eye on new versions of the
> original software. When the maintainer thinks a new version is worth
> packaging, she may package it as an "unstable" package to begin with,
> and then subsequently a "testing" package. If, as the release of a new
> version of Debian is approaching, the "testing" package meets
> sufficient criteria indicating its suitability for being regarded as
> "stable", then it, too, is marked as "stable" for that new release of
> Debian, and is thereafter treated as described above.

Well, yeah, maintainers aren't always on company payroll to maintain 
software.  We rather are at their mercy when it comes to this.

> 
> As such, Debian may have multiple packages for the same piece of
> software: "stable" packages for current and old versions of Debian,
> and "unstable" and/or "testing" packages. Usually, each of these
> packages will be based upon a different version of the original
> software. In a hypothetical case, the "stable" package for the current
> Debian stable release might contain version 3.1 of the original
> software (perhaps with security patches, as described above); the
> previous Debian stable release might have packaged version 1.0 of the
> original software. The current "testing" version of Debian might
> package version 3.9 of the original software, and the "unstable"
> version of Debian might package version 4.2 of the original software.

I'm not EVEN going to break out my soapbox on how freaking bad Debian's 
repos are, nor their horrible maintenance of said repos.  It's a 
complete joke.  This is the IDEAL case of a decent OS getting KILLED by 
it's horrible QA/Maintenance team.

> 
> But…
> ----
> 
> Sometimes, stability lets you down.

No, this isn't really accurate based on what you say below. This isn't a 
stability problem, but a problem with the individual maintainers.

> 
> My perception is that the greatest problems with the system of
> "stability" practised by Debian and other Linux communities arise when
> the upstream developer has not maintained the documentation for
> earlier versions of the software he has written. This leads to a
> disconnect between users reliant on package managemers and interested
> in dependability, and developers interested in making software that is
> faster, more fully featured, or otherwise different from the earlier
> versions of their software.

Look, it's true the OD (original developer) may not keep older versions 
up to date documentation wise.  That does happen, but that's NOT the 
package maintainers fault.  It /is/ their fault, however, if they 
include docs for a newer version of the software with an older version 
of the code.

> 
> An example
> ----------
> 
> Here is my scenario. I have a server running Ubuntu 8.04 LTS: a
> "stable", recent release of a Debian-based Linux distribution. I wish
> to install a security-related program called "psad" (short for "Port
> Scan Attack Detector) on that server. However, the stable package of
> psad for Ubuntu 8.04 turns out to house version 2.1 of psad. That
> wouldn't bother me, except that… I can't set it up!
> 
> The reason I'm having difficulty setting it up is that the
> documentation on installing psad refer not to version 2.1 but to
> version 2.1.4, which requires setting up differently to 2.1. The
> developer's recommendation is that I upgrade to a more recent version,
> but two questions arise:

Okay, are we talking documentation carried over with the package 
install?  Or on the apps' website?  If it's included with with package, 
then that's a problem with the maintainer simply NOT paying attention. 
If it's on the website, it's a bitch, but it does happen.  Most devs 
will leave older version docs posted but not all.  But then, that's what 
the community is for. :)

> 
> * how?
> 
> * why?
> 
> The how question has several possible answers. I could forego package
> management altogether for psad and install version 2.1.4 straight from
> the source code. But that would entail the problems outlined above:
> the problems package management solves. Alternatively, I could perhaps
> configure my server to attempt to use an "ubstable" or "testing"
> Ubuntu psad package in place of the stable one for 8.04.

There IS a third option not mentioned here.  You could build your OWN 
PACKAGE with the newer version of the software.  I've had to do this 
ALOT over the years for the very reason you describe, a package I want 
has a newer version that a binary package isn't available yet (or ever), 
or it's a newer app, but I need it on an older (unsupported) OS. 
(Typically an older fedora version getting newer software RPMs.  This 
gets you the latest version for the OS you want, and you can always post 
the newer package or submit to the current maintainer for him to debug/use.

I've done that as well. I don't mind posting the work I've done for 
someone else to use if I think it will be handy for a few folks.

> 
> But why? Why should I have to do this, if the "stable" package is good
> enough that it was chosen for "stable" release?
> This is where the disconnect I alluded to above becomes apparent.
> Developers may not always explicitly deprecate their old code, but
> they nearly always do deprecate it anyway. The response of Michael
> Rash, the psad developer, was characteristic of this.

Yes, but truly that's the 'stock' answer from ANY developer, to upgrade 
to the newest version.  Unless you are Microsoft, (r others) who get 
paid to maintain older versions of software, you won't want to do it 
that much.
> 
> Yet as far as users of stable distributions are concerned, that same
> sofware - the oldish versions of the program - has not been
> deprecated: it's still in the latest "stable" repositories.
> 
> There's a contradiction here.

This isn't a contradiction.  Not in a true sense of the word.  It's more 
'unfortunate' rather than a contradiction.  Any stable package is left 
in stable /until/ it's superseded by a newer version in any distro. 
That's because, if you pull it because it's not the newest, how would 
someone who needs /any/ version of that software to install it from a repo?

It's more aggravating than a contradiction.

> 
> Unfortunately, it's an unresolved contradiction, as far as I can tell.
> I encountered it previously with rkhunter, also a piece of security
> software I wanted to install onto a software running a "stable"
> version of Linux. In that case, it was even worse: the upstream
> developer had explicitly deprecated the version that was in the
> current (read: un-deprecated) "stable" package, and was entirely
> unwilling to support it.

Yeah, that's a bit of a pain, but that is also life in FOSS.  There 
aren't enough knowledgeable people with the time needed to put into 
maintaining all the packages (or potential packages) out there.

> 
> Clarification
> -------------
> 
> Despite these problems, I'm still very grateful to - and have a lot of
> respect for - the developers and maintainers of the software I use
> (including the software I've mentioned above). Michael Rash's software
> is innovative and free (in both senses of the word), and he was
> certainly under no formal obligation to reply to my queries.
> Furthermore, I have learned a good deal from reading his book.
> Equally, rkhunter *can* be a useful tool even if you aren't using the
> very latest version of it, and the maintainers who answered my queries
> also did so voluntarily and courteously.
> Yet the problem remains: when developers deprecate software that
> maintainers have not deprecated, users are left in the lurch with
> software they can't use, can't get much support for, or can't find
> documetation for.

Not always true, but I can sense your frustration.  It's a pickle to be in.

> 
> Solution
> --------
> 
> In some ways, I'm still very much a newcomer to the free software
> world. It's only in the last 2-3 years that I've really begun feeding
> back to the communities whose tools I use, and I have not become a
> developer or maintainer myself. As such, I'm not yet in a position to
> implement change to, say, Debian's release policy.
> Yet, I do have some ideas for solving the problem I've outlined in this piece:
> 
> * Raise awareness of the problem.

I'm almost sure they know the problem, and do what they can to eliminate 
it, but see my post above about manpower, it's just not there all the time.


> 
> * Propose that maintainers open a dialogue with the developers whose
> software they package to request that developers continue to support,
> or at least maintain documentation for, old versions of their software
> until the maintainers have deprecated it.

Again, see above.

> 
> * Ask the maintainers to shoulder this burden where the developers
> cannot or will not do so.

Look, maintainers do all they can to make that not a problem, but there 
isn't always a compelling need to update widget-1.0 to widget-1.1 until 
after everything else is done, or EVER if that app isn't used much or 
isn't maintained upstream.

> 
> * Seek further suggestions from the community.
> 
> In the first instance, I'm going to attempt to make some progress
> towards realising these solutions by posting a link to this piece to
> the Debian and Ubuntu mailing lists. Then I'll leave it in the
> community's hands unless I find I have any more to add.

We've all been where you are.  I was there just a few weeks ago. I had 
to build the patched BIND version for the Kaminsky exploit for Debian 
sarge for that VERY reason.  I also had to patch Fedora Core 6's BIND 
with a patched RPM I built myself.  It's not always fun, or easy to 
build them yourself, but it can be done when needed.



-- 
Frustra laborant quotquot se calculationibus fatigant pro inventione 
quadraturae circuli

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support