[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel 2.2 and Slink



Federico Di Gregorio <fog@debian.org> writes:

> On Sat, Feb 06, 1999 at 11:14:08AM -0200, Lalo Martins wrote:
> > Ok, it's too late to have kernel 2.2 in slink, as much as it was
> > too late to have apt in hamm. But we sneaked apt in hamm,
> > remember? I just read that RH made available an "upgrade pack"
> > [ http://linuxtoday.com/stories/2880.html ]. Perhaps slink CDs
> > could have a separate directory "kernel-upgrade" with all the
> > deb's necessary? Even if it's only kernel-source-2.2.x?
> 
> Hi *,
> 
> 	I really like the idea of "upgrade packs". Debian always had
> the problem of releasing very stable but with old versions of some
> programs (without a lot of features the new versions have). Yes you
> can download from the net (and I do that) but the classical (european,
> we PAY telephone) user don't want to play with unstable. A little
> set of tested, stable debs can be a real plus for some users (kernel,
> gnome, etc...)
> 
> 	I think we can even extend the idea and modularize a little
> bit the release of Debian (core+packs). There was a long talk about
> that in the past, I know, but nothing emerged from it...

Gnome isn't a great example of a "stable" package.  :-)

I don't believe that splitting the core packages (base, X, etc) from
the rest of the distribution will enable us to get our main releases
out any quicker.  Generally speaking, our releases end up getting held
back by the complexity of packages like the kernel, glibc, egcs/gcc,
dpkg/apt, X and the bootdisks.

Releasing "upgrade packs" of applications on a different timetable
than the core system will multiply the amount of effort needed to test
and release - depending on how many times more often the releases are
made (and the number of packages included).  I'm not sure the Debian
developers have enough time to devote to more releases.

I think the best solution is what we were doing with 'bo-unstable',
where programs from unstable would be "ported" so that they could be
used with the stable release.  This can be done independently from the
development in unstable by people who actually use the packages.  If
it were more organized, it would be a good way to get new people
involved with the project as porters/developers.

Cheers,

 - Jim


Reply to: