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

Re: creating kernel udebs from kernel-source

On Mon, Nov 29, 2004 at 01:46:24PM +0100, Fabio Massimo Di Nitto wrote:
> 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.


Sven Luther

Reply to: