Re: Old versions [LONG - lots of comments added in reply]
- From: amacater@xxxxxxxxxxxxxxxxxxxx (Andrew M.A. Cater)
- Date: Sun, 23 Jul 2006 11:13:15 +0100
On Sun, Jul 23, 2006 at 02:38:13AM -0400, Godless Infidel wrote:
On Sunday 23 July 2006 01:49, Kevin Mark wrote:
On Sun, Jul 23, 2006 at 01:34:42AM -0400, Godless Infidel wrote:
Is it true, as I have heard, that you must run "testing" or "unstable"
in order to run the recent versions of applications?
It varies. "Unstable" is unstable primarily in the rate of change: large
amounts of package churn, new packages to include relatively bleeding
edge software, sometimes packaged within a few hours of release. There are a
relatively few uninstallable packages at any one time: there may be
large chunks uninstallable for a period e.g. when KDE changes
major versions or there is a GCC change - that's usually only for
a couple of days/weeks as packages gradually work through to the updated
versions. There may be individual breakages in packages at any time but
they get fixed quickly. Unstable is usable all day every day - but there
may be some instability. It's never released as such: your "unstable" of
today's install is "testing" a while later ... see below. Sid codename -
Sid broke toys in Toy Story. [For rough comparison: X.org 7.0 moving to
X.org 7.1 here]
After a period, the packages move to "Testing". Testing originally had
the goal of being release ready at any time: packages percolate in, get
a period of hammering on and wait for a stable release. Some packages may
stay in testing for a long time - the release process takes a long time
- but stuff thats in testing is generally usable for all purposes at all
times. Stuff will still break from time to time: there will be active
updates tracking moves above in unstable. Close to a release as
stable, stuff may get dropped from testing if it's not release
quality. Currently Etch codename - will be released as stable
release Debian 4.0 in December 2006 if all goes to plan.
[Was X.org 6.8.2 or so -> X.org 6.9 -> moving to X.org 7.0]
Stable: REALLY stable - it's been testing for anything up to 18 months.
As it releases, it freezes solid. No changes except security related
changes or really huge bugs. No major kernel changes. No sneaky compiler
changes on updates. Debian will backport fixes to stable where
feasible so that stable essentially doesn't change behaviour. Some
people can't live with this pace of change, hence backports - building
e.g. OpenOffice 2.0 for stable using the compiler and libraries
within stable, producing it as a drop in package and putting it on a
backports server. Similarly, for Apache2. Currently Sarge codename.
Backports are not "officially" released - no major changes allowed to a
stable release - but it does mean that your system may stay more up to date.
It's your call: stable is essentially "fit and forget" and know that it
won't change for the lifetime of that release + support for (usually about)
a year after release of the next stable. [Debian 3.0 [Woody] has just
been dropped from support: everyone is now assumed to have updated to 3.1,
for example.]
One limiting factor outside your control may be the pace of hardware
change: latest whizzo computer with fast graphics card may not be well
supported on a two year old version of Xfree86: there have been similar
problems in the past with e.g. SATA/RAID controllers and being unable to
install at all . Conversely, stable may keep older hardware with
e.g. limited RAM happy for years. [Stable has XFree86 3.x]
Stable point release updates occur every few months, primarily to
address security issues. If I installed from 3.1r0 disks which I'd had
in the back of my cupboard for a year and immediately upgraded to 3.1r2,
I'd expect no more than about 100M maximum change: the idea is that
point releases bring you up to date not that they obsolete previous copies
- essentially, they just bring together all the changes since the previous point
release in one place - updating on line from the Debian security server
will bring you to essentially the same state.
Hi $NEW_USER,
Debian has many streams and each has a goal. Stable is meant to be
'released' and has 'release goals' like stabillty and specific features.
Since it is 'released' about every 18 months, it does not, by
definition, contain the most recent versions of any software.
Does it at least contain the most recent versions available at
release-time, or are they so afraid of introducing bugs that they
only use versions that have been out for a while?
See above: essentially you get well tested stuff that's been out
for a while because it's been in testing for a while but stable
freezes solid at release point - so Apache 1.3x, XFree86.
This is why people always complain that Debian is "old" compared to
SuSE 10.x / the latest Fedora / Mandriva / Ubuntu ... if they're
comparing with Debian stable they're comparing apples and oranges, not
comparing with Solaris 2.9 / Red Hat Enterprise Linux / HP-UX ...
But people who use it get 'enterprise-ready' and easy to use software.
If you want something that has more recent versions, you can run testing
or unstable. But you must deal with the shortcommings those version have:
they are less well tested, libel to not be 100% installable and have
changing sets of programs.
This seems slightly negative: I personally think the difference between
unstable/testing/stable is not day to day "stability" as much as pace of
change. I can work fine on unstable day to day - I just have to accept
that if I want to install 30 x exactly the same machine in a month, I
won't easily be able to because the software will have moved on.
Conversely, I can gradually "downgrade" an unstable system just by
installing it and leaving it for a while (month or two) then moving the
sources list to "testing" then moving "testing" to "stable" eventually.
If you upgrade to "unstable" to run a particular package, decide its
a mistake and want to go back to testing/stable quickly there may be
no immediately apparent and straightforward way to do this - to this
extent, downgrading is not supported. Its a good case for using
backports/waiting for a backport to be produced.
This here is my main concern with unstable. About how much of the
unstable distribution is uninstallable right now? If it's low enough
percentage-wise, I need not worry about how old the software in 'stable'
is.
It varies: taking a wild guess - out of 18000 packages in unstable,
possibly a dozen or two are uninstallable today - but will install tomorrow
or in a week's time, to be replaced by a few more that won't install :)
You may have to wait: on AMD64 unstable, though some help libraries,
lanugage packs and support and development libraries are currently
available, I'm waiting for OpenOffice 2.0.x to be 64 bit clean and
installable. It isn't - the current advice is to use the 32 bit version
in a chroot - but it's being worked on and will get here soon. There are
packages on the maintainers home site, he acknowledges bugs and they'll
be put into unstable when they're ready. This contrasts with the rush to
get out OO.org 2.x for other 64 bit distributions.
I use unstable, which has the most change,
but I would not run it on a production server, it is better suited for
experienced users who dont need enterprise-ready software, not that it
isn't close to that already. There is one way to use more recent
versions of some software on stable, that is to use 'backports'. Again
this is a compromise but one that many make. It takes more recent
version of important software for servers and recompiles that to work
with library versions in stable.
Are you talking about recompiling software outside of the package
manager, or do 'backports' work within the package manager. My
current Red Hat system is so full of such software (outside of
RPM) that there's no longer any point in trying to use RPM. I have a
directory full of the original source tarballs just to keep track
of what's installed and where it went during 'make install'.
You should almost never need to do this on a Debian system: everything
should be available somewhere within Debian, pretty much [if you
include backports (and the multimedia stuff including non-free codecs and
"stuff" packaged at debian-multimedia.org by M. Marillat) in this
loosely wider temporary definition of "Debian" :) ].
And since the subject of library versions came up, do
you know why new libraries are binary-incompatible with
old ones these days, even for applications that only use
the functions provided by the older library versions? I
remember a time when all you needed was a library with the
right symbols in it. But now, a simple program compiled
against the latest version of glibc won't work with an
older minor revision of glibc, because ld.so checks a
version number that is somehow embedded in the binary.
Debian packaging will allow you to have multiple versions of
"stuff" on your system. Proper package and library dependency checking
helps here and, IMHO, is the main reason for using Debian over any
other Linux distribution. Debian is "done right" at a fairly low level
:)
It provides an intermediate solution
for stable users but it again affect the useability of stable as
backports introduce a possible source of instability to the 'stable'
release while giving a bit of improved functionality.
cheers,
Kev
--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
- Follow-Ups:
- Re: Old versions
- From: Godless Infidel
- Re: Old versions
- References:
- Re: Old versions
- From: Godless Infidel
- Re: Old versions
- Prev by Date: Re: CUPS (Sid) not printing. (SOLVED?)
- Next by Date: Re: possible to merge partitions?
- Previous by thread: Re: Old versions
- Next by thread: Re: Old versions
- Index(es):
Relevant Pages
|
|
