Re: What's wrong with debian?
Roberto C. Sanchez wrote:
Quoting Hodgins Family <ehodgins@telusplanet.net>:
> These three points lead me to suggest some things: 1) Why not
> dump the concept of a "Release", altogether? (I'm referring to
> Potato vs Woody vs Sarge vs whoever is next.) 2) What we are
> actually running is either i) Debian Stable, ii) Debian Testing
> or iii) Debian Unstable or iv )a mixture. All are current up to
> whatever date we last ran apt-update && apt-upgrade.
A-men!
> 3) Debian Stable (up to whatever date we last ran apt-update &&
> apt-upgrade) is what (maybe) what Mike was referring to.
>
> Statements such as "I'm waiting for Sarge" become irrelevant.
<SNIP/>
I think that we need to consider the idea of "service packs." That
is, we have a stable release and periodically a set of packages (I
am thinking of a server-targeted approach here) can be upgraded
for functionality, instead of only security. For example, it would
be really nice if Woody had supported Postfix 2.1, Apache2, Cyrus2,
and so on.
I think that there are several potential benefits:
1) The core libraries (libc, and bretheren) can remain as they are.
Other applications can be upgraded to more modern versions.
Imagine if Mozilla 1.6 or 1.7 were in Woody instead of 1.0. The
issue of abandoning security support would not have been raised.
This, I suspect, is going to be a huge issue. The differences among
glibc 5 and 6, f'rinstance. To say nothing about the related issues
of /which/ gcc release will compile the source. Right now, a package
might compile clean (and even work) with gcc-3.3 and glibc++6 for
Testing, but it couldn't be dropped into Stable unless it compiled
clean and ran with gcc-2.95 and libc 5. Alternatively, would you call
it a ServicePack to drop gcc-3.? and libs into Current-Woody, and no
longer support gcc-2.95? Hell, a user can still pull down gcc-2.72!
I doubt the gcc team puts much effort into problems in those releases
. . . they are looking with baited breath at 4.0. [I may be behind
the times here].
Commercial vendors have often found it neccessary as a practical
matter to limit just how far back they can support -- usually 2
generations. Of course, that doesn't mean they would sell you the
Now-2. I guess backports.org would be our friend for stuff like that.
2) Or what about the very old version of some of the server
software. Most of it no longer has upstream support and has been
replaced by solid and stable versions released upstream. Seriously,
try finding information about configuring Postfix 1.1.
3) 1 and 2 combine to give a lower maintenance burden for the
individual package maintainers and the security team.
4) It keeps the distribution from lagging too far behind.
5) It also helps to smooth the transition between major stable
releases.
Actually, I would like to just set up my apt target as, say, "Testing"
to represent the degree of risk I can deal with. Then let the latest
and greatest of everything percolate down from the bleeding edge into
"Testing" as it comes to satisfy that degree of stability.
I am not trying to say that we should do the service pack thing
since everyone else does. However, I think that given the size of
Debian currently (and the resistance to targeted releases for
Dekstop, Server, etc.) I think that taking a group of carefully
selected packages, that have been evaluated and tested for
regression, and placing them into stable would be a Good Thing(TM).
Besides, I don't think that this is too far from where we are now
with the idea of point releases (like 3.0r4). I just think that it
would represent loosening of the criteria for inclusion of
packages in such point releases without a compromise on quality.
I am interested in hearing what others have to say about this.
-Roberto
I would also wish to have the degree-of-risk selectable on a
per-package basis. For example, I tolerate a lot of risk on
mozilla-firefox and -thunderbird ... I install the nightlies every
week. That is emphatically NOT the case for the kernel, for example.
I'm using a backport version 2.4.26 because it's the only one I've
gotten to work correctly with my darned nVidia hardware. I like to be
very deliberate about changes at that level, because they can be such
a pain to undo.
Anyway, this is basically a +1 for the service pack concept, and for
untying release "names" from risk-level (Stable, Gamma, Beta -- to use
Xemacs terminology; Stable, Testing, Something-else here).
--
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace, I am a Christian man; by my actions a great sinner."
-- The Way of a Pilgrim: R.French, Tr.
Life is too short to tolerate crappy software!
Reply to: