Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 01:46:24PM +0100, Fabio Massimo Di Nitto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sven Luther wrote:
>
> | On Mon, Nov 29, 2004 at 08:35:03AM +0100, Fabio Massimo Di Nitto
> | wrote:
> |
> |> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> |>
> |> Hi everybody, ~ right last week i have been asked to merge the
> |> linux-kernel-di-* packages directly into the kernel-source (that
> |> in Ubuntu we call linux-source) so that all the different binary
> |> packages are built from one and only one source. Basically
> |> killing kernel-image packages (that was done a few months back)
> |> and now linux-kernel-di-*
> |>
> |> The resulting diff of the merge (based on our linux-source) can
> |> be found here:
> |
> |
> | You can do this in ubuntu only because you have only 2-3 arches to
> | worry about,
>
> 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 :
1) the below mentioned technical problems, but you may have worked around
this, not sure 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.
> | and are thus not limited by the number of packages the packaging
> | tools can handle, right ?
>
> Nope.. the list of binaries that are generated per each arch is
> still relatively small.
>
> The control files grows in 2 directions:
>
> - - the first one is static due to merging the different kernel-image-*
> ~ into one source, but you still generate the arch specific packages
> ~ so the others are simply ignored.
Which may be a hindrance to keep kernels in sync in the debian case.
> - - 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 ?
> If you look at our pool for linux-source, you will see that the
> binaries are nothing
> more than what was before in the 3 splitted once.
3 is way less than 12 + the bunch of 2.6 kernels though.
Friendly,
Sven Luther
Reply to: