Trackin' stable vs. releases

[Alan DuBoff]

On Thursday 09 May 2002 09:00 pm, Rick Moen wrote:
> Well, to put it another way, I was trying to think of how to most
> effectively explain the Debian way of doing things to people (a category
> that on a good day might also encompass reporters).  I said one tack
> might be to say, in essence, there are exactly three Debian branches:
>
> stable
> testing
> unstable

Yes, this is true, even with the toy story names, since they merely point to 
the paticular branch they represent.

> I.e., I said picture a guy who installed 1.3/hamm when it was the
> current stable branch.  His sources.list says stable, so at intervals he
> resyncs.

This is partially true, but let's ponder on why that person may want/need to 
resync during the lifecycle of "stable" on their system. More often than not 
it seems that a piece of software would need to be installed the had a 
dependancy on a package that was not on hamm, wether that be gtk, glibc, or 
other common library. For me, I've found myself being in the situation where 
I was trying to install something and it wouldn't install. So I would resync 
to see if that would help the situation. In some cases, I may end up going to 
unstable, since as I point out there reaches a point in time that I do that 
for software(s) that I want on my system.

> Packages gradually improve.  The system slowly changes.  But,
> each and every day, he's running the Debian-stable release, current as
> of his last resync.  He hears news about "releases", but they aren't
> relevant to his system.  From his perspective, it doesn't matter if
> Debian ever "releases" again.  He'll just keep on running Debian-stable,
> whatever Debian-stable is at a given time.

Completely agree, until they finds themselves needing or wanting some 
software that is not on stable, and depending on how bad they want it, maybe 
they do as me and may decide to take it to unstable.

> The problem, of course, is that the LWN guy (if slink experience is any
> guide) doesn't get that Debian-stable _is_ the release in all senses
> that matter, and people who insist on continuing to track a release
> after it's discontinued just aren't clear on the concept, and is saying
> "I want my system to be decrepit and unmaintained".

Agreed, which is where tracking the release name gets you. As long as you 
stick to stable, testing, unstable, everything *should* work out for the most 
part.

> In fact, it would remain true if the
> Toy Story names and version numbers were abolished entirely, and
> everything were just referred to as stable, testing, unstable -- drawing
> from packages in the pools directory that change over time.

As long as I can get the package installed, it doesn't matter much to me. I 
would prefer to stay on stable all the time if I didn't need things that were 
in unstable and/or testing.

> But the question is, will you stay on _woody_?  Presumably, your
> sources.list currently says "stable"

No, actually right now it says woody, and it says that purposely. The reason 
is that it would normally be stable, but since I've been on unstable and that 
the names are only symlinks pointing to the actual branch, I don't want to 
continue on with unstable when woody is released. As my system(s) is now, 
it's on woody, and will continue to be on woody and when woody is moved to 
point to stable, I will then, at that point change it to stable.

> If you intend to use (in sources.list) specific branch names like potato
> or woody, or do so now, I'm curious about why.

No, I don't like to do that, and would prefer to use the branch name, but 
when the time overlaps between releases it's safer to stick on the toy story 
name because I know woody will be going from unstable to stable a specific 
point in time and it won't effect me.

> One wonders why you aren't on testing?

The biggest reason I don't like testing is that it presents packages that are 
linked with different versions of common libs, such as gtk++ or glibc and I 
would prefer that all of my software is compiled against a given version when 
possible. For a given release it seems this scenario is less likely to occur.

-- 

Alan DuBoff
Software Orchestration, Inc.
GPG: 1024D/B7A9EBEE 5E00 57CD 5336 5E0B 288B 4126 0D49 0D99 B7A9 EBEE