Re: what version?
From: Rick Moen (rick_at_linuxmafia.com)
Date: 09/19/05
- Next message: Nico Kadel-Garcia: "Re: Need Help With Soft Modems And FC4"
- Previous message: Mark South: "Re: Need Help With Soft Modems And FC4"
- In reply to: Nico Kadel-Garcia: "Re: what version?"
- Next in thread: Kai-Martin: "Re: what version?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 19 Sep 2005 05:52:55 -0400
Nico Kadel-Garcia <nkadel@comcast.net> wrote:
> [ This is getting long: if it's interesting and seems on-topic, cool, but
> let us know if we should take it offline. ]
OK, cool, though I'm unfortunately a little short of time. Apologies for
being a bit snippish, previously. I'll try to concentrate on casting
light on the subject.
> Thanks. The details of Debian are more clear in what you're explaining than
> I found them from the people I was working with. Unfortunately, their
> handling of RedHat package management had been jumbled by an architect who
> believed you should have your entire deployed software bundle as a single
> monolithic software tarball that overwrites the RPM-installed system files.
> That caused its own issues.
Believe me, I've seen this. Nobody's yet made a system that bad
administration can't ruin.
> Somehow they thought going to Debian would solve this, instead of
> actually learning to use the RPM system already in place and using it,
> instead of simply over-writing with wild abandon.
Seen that, too. I should stress that there's absolutely nothing wrong
with RPM-based tools and distributions. I like the yum toolset
particularly, and recommend RHEL rebuilds such as CentOS to people
frequently.
Further on in this post, I hope to cast a little light on characteristic
advantages of release-based approaches (such as RH, SUSE, etc.) and
characteristic drawbacks of the rolling-branch approach typical of
Debian, Gentoo, etc.
>> Doing a stable/testing or stable/unstable mixture, by contrast, is
>> unworkable because there's a _huge_ gap in versions, and you will tend
>> to instantly create a huge dependency mess.
>
> Agreed. Unfortunately, it's painfully common in my observations.
Yes, I've seen that, too. This brings me to the first of the
disadvantages of the Debian approach: It has entirely too many nasty
pitfalls, that tend to trip up the unwary. Their documentation doesn't
do anything like enough to ward off those mishaps. It would be
sufficient if they would even just put a few commented-out notes to
novice Debian admins in the default /etc/apt/sources.list file (the file
listing locations that will be consulted to find and make available new
package releases).
This is, I suspect, part of the reason that Ubuntu Linux, Libranet,
Xandros, MEPIS, Kanotix, Linspire, and other desktop-focussed Debian
offshoots have been so popular: The Debian distribution caters to the
needs of its developers, and leaves the problem of outreach to others.
[Point releases:]
>> Anyhow, too small for _what_? The point I was making is that Official
>> Debian 2.2r0, 2.2r1, 2.2r2, 2.2r3, 2.2r4, 2.2r5, 2.2r6, 2.2r7 were
>> functionally equivalent to RH 7.0, 7.1, 7.2, 7.3 during that same time
>> period -- except that Debian's releases were _much_ more frequent, which
>> is exactly the opposite of what you claimed.
>
> I wasn't counting the point releases. Are you saying that everything that
> worked with 2.2r0 migrated carefully and reversibly and interrupted
> correctly with 2.2r7? How big was the jump between 2.2r7 and 3.0r0? When did
> the change to a 2.6 kernel, or to xorg instead of XFree86 happen?
Those questions cannot be answered as posed, because they assume a
different maintenance regime than actually applies. I will take a few
minutes to explain.
As I mentioned earlier, Debian-compatible installation media (including
but not limited to Official Debian images such as the 2.2r7 ones) are
not primarily intended as things to run but rather as points of
departure in building a system that then gets maintained by
incrementally following one of the development tracks. That is, at the
end of initial installation, you adjust /etc/apt/sources.list to specify
which package sources you wish to follow, do "apt-get update && apt-get
dist-upgrade" (or the equivalent via one of numerous front-end shells
for package management), and do "apt-get install kernel-image-[foo]-N.N.N"
to grab an initial runtime binary kernel to replace the installer's
kernel.
If your initial system build (and, let's say this occurred while 2.2 was
the Debian-stable branch) was conducted with a set of Official Debian
2.2r0 CDs (and there are many other Debian-compatible media -- see
"Installers" on http://linuxmafia.com/kb/Debian), then by the time
you've completed the immediately post-installation adjustments using the
apt-tools, you already have a system considerably more advanced than the
one the 2.2r0 disks load. Let's say that, very week, you do "apt-get
update && apt-get dist-upgrade" to re-sync your system to the available
packages. On 2000-11-12, the Debian Release Manager took a snapshot of
the stable-branch archive, because he felt it was in particularly good
shape, and declared that "2.2r1" for the benefit of CD vendors and such
-- but you'd already have a slightly more advanced Debian-stable system
before any new CD sets could arrive in the mail, because you're pulling
down updates periodically and keep pulling ahead of what the vendors can
sell.
You do not seek to upgrade from a "2.2r0 system" to a "2.2r1 system"
because the implied concepts simply do not make a lot of sense in the
Debian context: 1. Nobody with a grain of sense seeks to _run_ a
"2.2r0 system": The disk images were a convenience for constructing an
initial system. 2. Nobody on Debian-stable of that era would have
aimed to upgrade _to_ a "2.2r1 system": Ordinary system maintenance
would have already given you a more advanced Debian-stable installation
than the 2.2r1 discs would create, before you would have been physically
able to get them in the mail.
Kernels: Let's say that you originally build a Debian-stable system
with a 2.4.18 kernel on your dual-proc PII system, represented by this
package name:
kernel-image-2.4.18-1-686-smp
(I hope I don't get this wrong; I'm a little fuzzy on this matter.)
The "1" is package versioning as opposed to kernel versioning, and the
"686-smp" is the flavour of compile, i.e., 686-optimised and compiled
with SMP support. But the _package_ is "kernel-image-2.4.18: Absent
the sysadmin deciding to install somethign different, routine
maintenance would autofetch only newer _package versions of the same
kernel release and flavour, e.g., "2" (etc.) instead of "1", when "2"
becomes available because, say, of a kernel security fix.
That is the _general_ case. There are also virtual packages such as:
kernel-image-2.4-686-smp
Installing that virtual package would instruct the apt system to
autofetch newer kernel-image-2.4.NN kernels for higher values of NN as
they come out (fetching the 686 SMP flavour). The same also applies
with:
kernel-image-2.6-686-smp
And so on.
I suppose in theory there could be a virtual package called just
"kernel-image-686-smp", in which case you could autofetch the highest
numbered kernel release available in your compiled flavour at any given
time, but there is currently no such virtual package.
XFree86/X.org: Let's say your initial installation includes some
versions or other of packages xserver-common and xserver-xfree86, the
latter giving you (say) XFree86 4.3 server binaries and libs. In
the course of ordinary system maintenance, you would not suddenly switch
over to packages xserver-common + xserver-xorg without your specifically
requesting that change.
So, in asking me how system maintenance would incrementally take you
from a pre-2.6 kernel to a 2.6 one, or from XFree86 to X.org, you asked
me how the system would do (by itself) something the system does NOT do
(by itself) -- for the extremely compelling reason that doing so would
be foolish and would override the admin's express intentions. Debian's
design tries hard not to override the admin's express wishes.
Gap between 2.2r7 and 3.0r0: Again, people do not seek to _run_ 2.2r7
or 3.0r0. Those are merely installation images people used to construct
initial systems. However, something a _little_ like what you were
talking about does happen from time to time, and bears discussion:
The Debian Release Manager's job is to get the current "testing" branch
into a stable and maintainable enough state that it can be declared the
new "stable" branch, supplanting the old one. Let's say I'm running a
Debian-stable system in July 2002, in the latter days when 2.2 "potato"
was still the stable branch. Every Tuesday, I do "apt-get update &&
apt-get dist-upgrade" to get maintenance upgrade packages. My lines in
/etc/apt/sources.list specify "stable" as my branch to follow.
In mid-July, (say, unbeknownst to me), the Debian Release Manager
suddenly declares that the then-current testing branch, 3.0 "woody", to
be ready to go as the new "stable" branch. The "stable" and "testing"
symbolic links on ftp://ftp.debian.org/debian/dists/ get re-pointed by the
ftp-masters staff. Let's say I do "apt-get update && apt-get
dist-upgrade" the next day: I may or may not notice, but I'll get a
larger clump of packages than usual, and my system, albeit still
pointing to the "stable" branch, will have smoothly transitioned from
2.2 to 3.0.
How smoothly? It's the Release Manager's job, in part, to ensure that
system do not break when this happens. He makes sure that it occurs at
a time when the testing branch is in a very good state and test upgrades
have gone very well. Suffice it to say that it's fairly common for people
to smoothly progress from an initial Debian 2.1 "slink" system through
stable=2.1, then stable=2.2, then stable=3.0, without really being quite
sure when each transition happened -- or to notice each step for a while
thereafter. They might say "Oh, I see that /etc/debian_version now says
'3.0': I must be on woody, now."
But I personally haven't maintained Debian-stable systems for a long
time: They're rather _too_ boring. Debian-testing and mixed
testing/unstable systems do get a lot more update packages each week
(package churn), but on the bright side make it even _easier_ to ignore
the release process as irrelevant to one's situation.
And that is the characteristic advantage of Debian's (and similar's)
rolling-branch approach: You remain a constant distance away from the
bleeding edge with absolutely minimal effort -- and get an incrementally
moving system that tracks the advance of your chosen branch.
The characteristic drawback of that regime lies mostly in support
requirements of binary-only proprietary software that you choose to run
on your (e.g.) Debian system: While software _in_ the Debian package
archives will work pretty much indefinitely, because any odd
dependencies are noted in your /var/lib/dpkg/status installed-packages
database, and will be protected in perpetuity, proprietary software with
brittle system-software dependencies like, oh, let's say Metrowerks
Codewarrior for Linux, may get broken when a new glibc slides in.
There are ways you can register such dependencies into the system;
people more often than not don't take the trouble to use them, and,
besides, proprietary software vendors are often maddeningly vague about
the _real_ dependencies of their software: They're rather just say
"certified for RHEL 3.0 and SUSE Linux Profesional 9.3", instead of
"requires glib v.foo and lib-bar v.baz".
RHEL is a release-oriented system. (Fedora Core is more-or-less so,
though if you're relying on it for critical systems, you're a braver man
than I.) Debian tends strongly towards a rolling-branch incremental
change model, which makes it in general much easier to keep healthy, but
not as easy to keep in line with proprietary-software support models.
> If I need the SSH security fixes for a machine installed as 2.0r0 and
> another as 2.0r7, do I get the same OpenSSH package, namely the same version
> of OpenSSH as 2.0r0 orignally installed but with patches? Then 2.0r0 and
> 2.0r7 seem not to really be differeent OS releases, but rather patch levels.
Mu. ;-> Neither one is a development target or a "release" in the
sense you're contemplating. They're installation media -- starting
points. People with RH backgrounds think of the distribution as being
(to a first approximation) the set of software that come on the CDs;
people with Debian backgrounds don't. They think of "Debian" as the sum
of all available packages on each branch's package-mirror collections at
any given time, that collection being a slowly moving target that
evolves.
This is slightly more true of testing and unstable than it is of stable,
because of one difference. As a matter of policy, the only new software
permitted into the stable archive between major releases is whatever is
required for bugfixes and security patches. You don't get new stuff;
you only get fixed versions of old stuff. That's part of what makes the
stable branch boring -- and ultra-reliable.
-- Cheers, "Due to circumstances beyond our control, we regret to Rick Moen inform you that circumstances are beyond our control." rick@linuxmafia.com --Paul Benoit
- Next message: Nico Kadel-Garcia: "Re: Need Help With Soft Modems And FC4"
- Previous message: Mark South: "Re: Need Help With Soft Modems And FC4"
- In reply to: Nico Kadel-Garcia: "Re: what version?"
- Next in thread: Kai-Martin: "Re: what version?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
