Re: Future of the linux udebs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bastian Blank <waldi@debian.org> writes:
> On Fri, Feb 15, 2008 at 04:40:47PM -0200, Otavio Salvador wrote:
>> 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.
>
> So? If we need to update the kernel themself, it is also needed.
But it's obviously something to avoid.
I know that there're alternatives however it's not the best option.
>> >> 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?
>
> The list contains module X. This module got removed. What should happen
> with the build?
> - Fail silent. Ignore the error and don't output any udebs.
> - Fail loud.
>
> The first variant needs to be used if the list is included from an
> external source if it should not break it complete. I won't implement it
> because the build output is not longer reproducible.
I think it should fail loudly.
Yeah, after thinking more about it I figured that if we choose to go
for udebs being build by kernel source packages, we does need to have
it in the kernel package source.
>> This
>> would allow us to keep control about what would be end in d-i kernel
>> modules packages.
>
> We have to process it anyway and will be able to change it in any way we
> want. This is called trust.
While I agree that it's suppose to work, I also think that it can
bring serious discussions like we had lately (because of 2.6.24
migration to testing).
If we were already using this schema, the Beta1 release would need to
delay since we do not have 2.6.22 on sid anymore.
For me, to think more about it, we need an agreement from kernel team
that d-i can veto uploads of kernel. Obviously d-i team won't deny any
upload with real reasons however this agreement this is a must from my
POV.
Let me express my conclusion up to now for this thread (even I still
want to see a comment from Colin, Joey and Frans on this):
- if we choose to go with kernel sources building udebs, k-w is dead;
- kernel team needs to accept nacks from d-i team for badly time
uploads (this is a must);
- time needed for migration to new kernel would be reduced a lot;
- tests would be need, for d-i, from snapshots of kernel;
Cheers,
- --
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFHt0qSLqiZQEml+FURAs1HAJ43XrO2zga1AZtHDvsQwUjxYpGHvACgkPRh
a6AzostXhbnMNenQ9B1NDT0=
=Kwqe
-----END PGP SIGNATURE-----
Reply to: