Re: creating kernel udebs from kernel-source
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sven Luther wrote:
|
|
|> |> | multiplied by the number of architectures plus the number of
|> | |> architectures having 2.6 kernels. |> |> ??? this makes no
|> sence to me at all. and we are only talking |> about one kernel.
|> |> |> You only multiply once by the number of arch. | | | Nope.
|> you have the 2.4 kernels and the 2.6 kernel, so you add the |
|> total number of kernels which is between the number of arches and
|> | two time the number of arches.
|>
|> The patch doesn't merge kernel-source-* into one big kernel
|> source that includes ver 1.0 to 2.8. It applies to only one
|> kernel source (let say 2.6.9) and from that one generate propers
|> udebs for the arch where it is building.
|
|
| Ok, my fault, so we still have all the 2.4 and all the 2.6 kernels,
| That still means 303 .udebs for the 2.6 kernels and 436 for the 2.4
| ones. Not counting the .debs that needs to be generated too, which
| should amount to 10-20 packages, if i am not mistaken (powerpc 2.6
| has 20, and 2.4 has 37, while i386 2.4 has 23).
Yes but the control file that is generated doesn't include all of them
at the same time. That's the whole point of it. You still get control
files x arch. That reduces the amount of binary packages processed
in the run only to the ones that are actually generated. You will
never get 300000 udebs together.
|
|> | Actually, you have to take every available flavours as you |
|> mentioned above. On powerpc this is 5 for 2.4 kernels and 3 for
|> 2.6 | ones for a total of 8. (2.4 : powerpc, powerpc-small,
|> power3, | power4, apus, 2.6: powerpc, power3, power4, soon to
|> come ppc64 | iserie-legacy, generic and generic-power4
|> additionally, and i have | had at least one case where the UP
|> kernel failed and a SMP kernel | is needed, so maybe we should
|> double some of these).
|>
|> You don't build udes for all the possible flavours simply because
|> there is no need to. You build udebs only for the minimal amount
|> that you need.
|
|
| Sure you do, since these kernels are *incompatible* on the
| instruction level set. And i wish you much luck trying to modprobe
| a powerpc module into a power4 kernel. Or in an apus kernel for
| that matter.
We are saying the same thing Sven, if on ppc you need 3 or 4
flavours it is ok, but there is no need to generate udebs for
the -smp versions (as example). There is really no point since later
the installer
will take care of installing the proper kernel for the machine.
I am not into ppc as you are but let's make a netrual example:
arch foo has 20 kernel flavours, like foo32 foo64 + their -smp variants
and whatever you want to add to it, but all of them can boot and install
from a subset of them, like foo32 and foo64, you don't need to build
20 sets of udebs, but just the common ones that can manage to boot
everything since the installer will make the proper decision later.
|> I doubt anybody will ever require -smp udebs, right?
|
|
| I was not counting those in the above, we don't build them yet, but
| i know of at least one power3 machine which worked fine with the
| -smp kernel, but failed with the -up one. So i would be cautious
| about this.
That might easily bug in the kernel, because i can bring example in the
other way. This still doesn't mean that it is d-i task to workaround this
kind of problems introducing extra sets of udebs
Fabio
- --
Self-Service law:
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQaxDiFA6oBJjVJ+OAQIQ+xAAiTl9VOIxut8zA2aDsvdjwN7TZgp8e0QW
bCOBqYd+rE0duZG3iYJ5BFZrcFkrf7OOyNjqHsxqfAsn4csnq7XWIOpcq2aZ9qjw
5GUFXzNEKzYQEz7j/jLfWO7DyacOA6t0C/3f1lrY+rZ2cDbqZdDnkNp0y9U+4lQn
w1VYfBp1DGe6q3bQJY0vMgmTxFRefNdED4q26YJm357pglton238qEjz28StJ2u2
xFXiuxBrHAiQs1UQ9gdrhfqJBAykt7SlrLEGFghy5WKtqKabjSVFyFnDKrVmFN18
bmTNPB1kMplZDR8Yj4cSpkqEoTOnScpISumIf0ipTY3vftz5gdndshyVniwXSPwL
MRLssa7V0a8fXznk5Vjp/Jec5r6U3eAFPJOIqpgGslThggcCmhPOZOrGD8uUJZ7d
779+J6delelRJQujsE+nx3h819OFyNeH9uD/cFRd3dD65YDKfowDdeOZy5GScl9K
ZQCrSV0JGb0FHzZNCDbgiUa4ZCpmReRnyOSbFYAerstyGCvfQ7ZYdHTGFCGckpSG
1hIc8b6GkBK6QTy2zIChz5CPttM89qZJlwg8G2H/ZjQ8YPFfTByqb+Ij5of3ROMD
K4WFBC1kKJKSQyv8CufqUmtPaTUfy/zHOCw6auVMSOB5EeNiY3EbAvNmB+CHBYlY
ZJZWwHI4PHU=
=aMVy
-----END PGP SIGNATURE-----
Reply to: