Re: Future of the linux udebs
Bastian Blank <waldi@debian.org> writes:
> On Fri, Feb 15, 2008 at 02:13:02PM -0200, Otavio Salvador wrote:
<...>
>> 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 ;-)
>
> I still don't get you.
Kernel udebs on testing came from sid. So they're suppose to be
uploaded there and migrate.
If a unwanted kernel is uploaded to sid and we wanted to update the
udebs, for a release or something, we would end up doing it
t-p-u. This would be done with minor testing and possible breaking
lenny installer.
That's why it should be avoided as possible.
>> >> 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?
>
> It's the only solution which will not kill new versions without code to
> ignore udebs if the definitions are broken.
Didn get you here. Could you elaborate it a bit?
>> This means kernel-wedge will be useless and _any_ change would be need
>> to be done on kernel team svn.
>
> The list needs to be available during build of the source package, it is
> not possible to change them after that.
Sure. But it could be available from kernel-wedge or something? This
would allow us to keep control about what would be end in d-i kernel
modules packages.
>> This is a big regression from my POV
>> since d-i team does need to be able to change the list by himself.
>
> There are two sorts of changes:
> - Modules got renamed/merged/removed.
> This will kill the build if not fixed, so we need to be able to do
> such changes on ourself.
Right.
> - Modules got added.
> This may have an effect, but usualy it is new hardware support.
>
> Now please explain why you _need_ to change that directly and produce
> the following workflow
> "mailto:d-i, commit, upload k-w, mailto:kernel, commit, upload l"
> instead of
> "mailto:kernel, commit, upload l".
> This is a classical indirection.
The problem of doing it directly inside of kernel is that we'll lose
the control of what is being deployed and we'll then need to get
informated about every change inside of kernel packages to get this
information sorted out.
If this could be done from a d-i package (k-w or anything) it gives us
a cannonical place to look at and don't force us to follow another
commit mailing list to get the need information.
>> This looks
>> logical since we'll be directly affected by it and the installer might
>> break.
>
> Everything might break.
And we need to try to avoid it as possible.
--
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."
Reply to: