Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 02:55:20PM +0100, Fabio Massimo Di Nitto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sven Luther wrote:
>
> |>
> |> The model can be adapted. I am not pushing a patch to force our
> |> solution, but to give back the code that has been done and
> |> tested. It is up to the 2 teams to decide what to do with it.
> |> Clearly applying it to 11 arch is technically possible, it of
> |> course require more coordinations between people, and that is
> |> something nobody can give you with a patch ;)
> |
> |
> | Well, sure, i was wondering about two things though :
> |
> |
> | 2) a little change to the powerpc or x86 kernel will mean a full
> | rebuild for m68k or arm too, right ? Maybe not an issue for pure
> | udebs things though.
>
>
> That is correct. As everything in this world you win on something and
> lose on something else.
>
> The cons is that, clearly, each time you upload the kernel it will build
> everywhere, even if the change is unrelated to the arch you are building
> on.
>
> On the otherside, you might want to think to security or bug fixes
> that needs to spread across all archs. One upload the fix is
> "automagically"
> redistributed everywhere. From the source to the last udeb.
>
> As it is now, someone needs to upload kernel-source, someone needs
> to wait for it on the mirror and upload kernel-image and upload
> kernel-image.
> The d-i team, at the end of the wheel, needs to wait kernel-image and
> then upload linux-kernel-di...
> The last 2 bits repeated for N archs.
> But i guess you already know this :-)
>
> |> - - the second one is slightly more dynamic and it involves the
> |> addition ~ of the udebs to the control file at build time, but
> |> they are still arch specific.
> |>
> |> So at the end you get nothing more than what you had before, just
> |> from the same source.
> |
> |
> | Which i was led to believe that the packaging tools could not cope
> | with 6 month or so ago. Maybe i am wrong though ?
>
> I am not really sure what you are talking about, but we have packages
> in the archive generating way more binaries that what this solution does.
Imagine all the .udebs for all the modules plus the kernel, multiplied by the
number of architectures plus the number of architectures having 2.6 kernels.
That was by far the most .udebs any package could hold, and it did break. Ask
Colin, he knows about that.
Friendly,
Sven Luther
Reply to: