On Wed, Nov 16, 2005 at 12:39:03PM +0900, Horms wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Package: linux-2.6 > > Severity: normal > > > > > > Well, this is something that came up with the desire of not using the > > (currently broken) initramfs-tools on alpha. We need two implementations to > > fix this, or at least one of them but the other seems useful too. > > > > 1) gencontrol.py should know how to handle an 'excludes' field, which will > > be used to remove any reference to the entries in it when generating the > > depends and such fields, this would be used as : > > > > arch/alpha/defines: > > ... > > excludes: initramfs-tools > > > > and the line : > > > > Depends: yaird | initramfs-tools | linux-initramfs-tool, > > module-init-tools (>= 0.9.13) > > > > would be rewritten to : > > > > Depends: yaird | linux-initramfs-tool, module-init-tools (>= 0.9.13) > > > > 2) We need support for setting INITRD_CMD prior to the make-kpkg command > > which creates the postinst (i thinkg the kernel-image one not sure though). > > > > This would allow to do : > > > > arch/defines : > > ... > > ramdisks: mkinitrd.yaird mkinitramfs > > > > arch/alpha/defines : > > ... > > ramdisks: mkinitrd.yaird > > > > The first one would be nice to have, we currently keep the full depend and > > add > > a conflict on alpha, but i believe the second solution is better, altough it > > needs k-p 10.000x. The reason why the second fix is better, is that there is > > really no reason to stop alpha from installing initramfs-tools, just we have > > to make sure not to use it by default. > > Agreed. > > I'm somewhat dubious about the need for 1) as we do have a > mechanism, albeit a little tedious, to effect these kind of > dependancies. And in this case at least 2) shows us that > there is actually a slightly deeper problem that needs to > be addresses. I'd be surprised if we really end up needing > 1).
i am fine with 2) only. It seems Bastian has already implemented it, altough in a more complex way, not sure if it is overkill or not, but i guess it will do the job. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
