[kwlug-disc] definition of debian's "stable"?

[L.D. Paniak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Robert P. J. Day wrote:
> On Sun, 16 Aug 2009, Eric Gerlach wrote:
> 
>> On Sun, Aug 16, 2009 at 12:59:50PM -0400, Robert P. J. Day wrote:
>>> On Sun, 16 Aug 2009, L.D. Paniak wrote:
>>>   that seems fairly adamant that, once you install a new "stable"
>>> release, the *only* updates/upgrades you will see are
>>> security-related.  no big fixes or performance upgrades.  or am i
>>> misreading that?  or does a 5.0.1 or 5.0.2 "release" represent a
>>> new release that *does* incorporate bug fixes?
>> I believe this is true.  Bug fixes, other than security, are allowed
>> in point releases.  Typically, major versions of packages are not
>> allowed, though.  The fixes usually have to be backported to the
>> current version in stable.
> 
>   aha!  he said, happily drinking wine.  i just learned something else
> significant.  the debian FAQ points out a fairly basic fact of which i
> was unaware -- that 3.0 was a totally different *release* from 3.1
> (3.0 being woody and 3.1 being sarge).
> 
>   which only confuses me more.  so if i was working under 3.0, would
> 3.1 be the next major release?  it seems that way.  and if that's
> true, how does 5.0 relate to 5.0.1?
> 


The versioning rules changed with the release of Lenny.  New epoch, new
rules.  Sorry.

In the good old days, updates were marked with a revision "r" number.
ie. Etch updates were 4.0r1, 4.0r2, ...

Even deeper into Debian's history, you have the Woody 3.0 vs. Sarge 3.1
issue.  Two different releases, different kernels...  Why? Why not? Even
more: 2.0 Hamm, 2.1 Slink, 2.2 Potato.

I don't believe that the version and update protocol were a big deal for
the Debian team until recently.  Personally, I don't worry too much
about the numbering so long as the software works. Seriously, I believe
that much of the improved formalism in Debian is due to the influence
(and requirements) of ubuntu.

There is the possibility of big (functional) change within a release.
Eg. 4.0r4 "Etch-and-a-half".  New kernel, updated packages, big
download.  It happened before and it will happen again with Lenny.  This
time it will probably be 5.0.6 or something.  Or maybe 5.1.

I thought that weekly updates also included small bug fixes, but this
may be because of the fact I run mixed systems stable/testing/unstable.
 The packages from testing and unstable see continuous updates.  Another
reason to run a testing system!

A more conservative approach to get pending bug fixes to stable sooner
is to source "stable-proposed-updates" in apt/sources.list.  This will
give you  continuous access to fixes that will appear in the next
release update. Sounds something like release-updates (eg.
hardy-updates) in ubuntu.
Details at:
http://wiki.debian.org/StableProposedUpdates

BTW, aptitude on the command line is my tool of choice for working with
Debian repositories.  apt-get is good if you know exactly what you want.
 aptitude gives much more info and has gotten very good at resolving any
conflicts that might pop up.

You can also upgrade packages at your whim by dipping into the testing
or unstable repositories.  For small system deltas like applications,
this is not a problem.  For lower level things, this can be a good way
to muck up your system.  Usually it is quite safe:  I often run a stable
 release with a testing kernel and piles of applications from unstable.
Can yum do that?


Here is the apt How-To for Sarge (strangely enough):

http://www.debian.org/doc/manuals/apt-howto/index.en.html#contents

It is a little old, but I don't think the details of apt functionality
have changed much in the five years I've used it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKiLwH8h2PnOHbiQcRAmGZAJ96TRm3Qr4/uOVsQF8B5539IEzkbgCgl2Qw
HTUm80iC0idSwtSsU+HwdrQ=
=yHdk
-----END PGP SIGNATURE-----