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

Re: Future of the linux udebs

Hash: SHA1

Bastian Blank <waldi@debian.org> writes:

> On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
>>   - Is impossible to release d-i with a different kernel from sid
>>     without a lot of hassle
> d-i releases are built with testing udebs. Or do you mean something
> else?

Not during development cycle.

And the udebs on testing migrated to it from sid. I hope to not need
to do uploads to t-p-u for d-i kernel ;-)

>>   - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i
>>     development is affected
> If a bad glibc is uploaded, anything is affected. With such sort of
> arguments you can kill anything because the propability that something
> will get wrong is always larger than zero. We do a lot to not let really
> broken things through and I don't think you will be able to catch more
> problems.

Right. But it is a cons since currently we only migrate to the new
kernel when it's already widly tested on sid.

>>                   For it to work testing images, _before_ the kernel
>> upload to happen, would be required to at least reduce the risk of a
>> kernel upload to stop all d-i development until it gets fixed.
> We provide a snapshots archive which can be used through the whole
> development cycle.

Yes, right. We'd need to setup some way to get d-i builds against
those images and do testing using it before major kernel version

>> Another thihk that I see as a _must_ is that d-i team could nack a
>> kernel upload. This is requred since d-i won't be allowed to diverge
>> from sid kernels anymore (I mean during development) and those
>> migrations would need to be much more coordinated with d-i RM and d-i
>> porters.
> We coordinate the uploads on d-kernel@, for security uploads the waiting
> period is usualy a lot shorter. If someone have a problem, he can speak
> up and his concerns will get heard.

I'm not wondering about security uploads but about ABI changes and
major kernel version updates. Those would need to be coordinated on
debian-boot too.

I guess that a notice about upload, few days before, to debian-boot ml
should be enough, for ABI changes. For major versions, we'd need much
larger coordination since it would affect whole d-i.

Obviously, as already spot by you, we can get images built against the
kernel snapshots but we'd need  to get an infrastructure to get d-i
images built against it and tested before approval for the kernel

>> linux-2.6/linux-modules-extra-2.6 would build the udebs using what
>> list? Still using kernel-wedge?
> They need to include the list themself, it will get version dependant.

So your idea is to this list be placed inside each source package?

This means kernel-wedge will be useless and _any_ change would be need
to be done on kernel team svn. This is a big regression from my POV
since d-i team does need to be able to change the list by himself.

>> How the uploads of kernel would be coordinated? Will kernel team allow
>> d-i to _nack_ a kernel upload?
> Not for uploads which fixes bugs like CVE-2008-0600. A "nack" without
> anything may also not have any effect. But if there are concerns we
> should be able to find a solution which both sides can live with.

I agree that security uploads are exception here however any other ABI
or major version update would must to be acked by d-i team. This looks
logical since we'll be directly affected by it and the installer might

- -- 
        O T A V I O    S A L V A D O R
- ---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- ---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>


Reply to: