Re: Rethinking stable updates policy
John Goerzen wrote:
> On Sat, Aug 26, 2006 at 08:43:53AM +0200, Martin Schulze wrote:
> > John Goerzen wrote:
> > > Examples of things that should happen in stable, but haven't been
> > > happening reliably:
> > >
> > > * Kernel updates with more broad hardware support
> >
> > This requires new kernel packages, new utilities and a new installer.
> > It a hell of an effort to get this done. Just look at what it takes
> > to update these in stable with "only" security updates.
>
> New kernel packages, and a rebuilt install image, yes. New utilities?
> Which utilities?
I already forgot most of them again, but among the packages required were:
mkinitrd
kernel-package
debhelper
yard
Just try to get a more recent kernel from backports.org on a sarge
machine and you'll see.
> The only one I'm aware of that breaks with newer kernels is udev, and
> hasn't that been fixed for awhile now?
Oh, right. udev as well. I prayed for the machine to boot as it was
in a data center several km away from me. *sweat*
> I'm not talking about something like 2.4 to 2.6, just point releases
> within 2.6.
I'm talking about 2.6.8 (sarge) to 2.6.15 (current kernel that time)
> > It would be good, though, especially in order to have some support for
> > hardware that has entered the market after the last Debian release, if
> > there would be an outside repository for updated kernel and installer
> > packages. However, nobody considered this important enough yet.
> > (Hint! Hint!)
>
> Well, a repo for updated ISOs would be more useful to people, I
> think. But again, when somebody goes to debian.org to download
> stable, they'll get something that doesn't work.
That's something that could be done afterwards, but I agree, that
updated iso images, at least for the businesscard and network
installation would be great as well.
> It would be better to, say, issue 3.0.1 with a newer kernel package.
> This wouldn't even have to cause any impact at all to existing
> installations.
As I told you already, just look at the progress to get an updated 2.6.8
inclusive installer into the 3.1 stable release. It's problematic
enough already, not to speak about a new kernel version and new tools
and modified installer code, and differntly behaving packages, and and and.
> > > * Infrastructure updates such as ClamAV and Spamassassin
> >
> > We already have this in form of the volatile archive. That's exactly
> > what volatile is for and why it has been started. For these packages
> > it works quite well.
>
> True, but it would be better to make it more official. Plus, are you
> going to stick X, PostgreSQL, and MySQL in volatile?
No, but into backports.org.
We're trying to get volatile more official, to be continued...
> > > * Updates must undergo testing, ideally with peer review
> >
> > For this we don't have the infrastructure with regards to stable, and
> > it's also not possible to update stable just again because we noticed
> > that Firefox creashes 50% of the time. Backports is much easier to
> > handle for this and should be used.
>
> If this stays small-scale -- and it should -- this could be as simple
> as having, say, 5 trusted developers' GPG signatures on a message
> saying they have evaluated it against standard criteria and it passes.
> Doesn't have to be a massive thing.
That's not sufficient when new versions of software are included that
behave different, hence, break scripts, break users impression and the
like. That will make Debian stable an unstable system. This is not
what we should aim at. Really.
> But you're right, we would absolutely want to make sure we get it
> right. It's a hurdle, but I wouldn't call it insurmountable.
Such updates should be provided as an add-on like with the
backports.org archive. Then users can decide if they want to try an
update and maybe become happy with it.
By the way, I've been told that a more recent Firefox is already
included in the backports archive. Feel free to use it.
> > > * Updates must be drop-in compatible with the released stable --
> > > no config file incompatibilies or new debconf prompts, no new library
> > > so versions or deps on libraries not in stable, etc.
> >
> > This rejects packages like the kernel or Mozilla and friends
> > already.
>
> Again, I am confused about why this would reject the kernel, since in
> my experience, it *is* drop-in compatible.
Well... not at all. It may require a more recent udev, more recent
hotplug, more recent mkinitrd, more recent $foo, old drivers that
formerly worked, may not work anymore, old firmware (sorry,
binary-only, non-free crap) that was used formerly may not work
anymore since a newer version may be required. Devices may be named
differntly even without udev (think of two SCSI adapter whose order is
switched for whatever reason, this has happened already).
Regards,
Joey
--
Have you ever noticed that "General Public Licence" contains the word "Pub"?
Reply to: