Bug#338431: linux-2.6: [infrastrucutre] gencontrol.py should know how to exclude stuff from deps, add INITRD_CMD setting.

[Sven Luther <sven.luther@wanadoo.fr>]

On Wed, Nov 16, 2005 at 12:39:03PM +0900, Horms wrote:
> In article <20051110085820.GA20904@localhost.localdomain> 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