Re: [PATCH 3/3] dracut has initrd-generic-<version> instead of initrd-<version> (#519185)
Hi,
On 09/03/2009 06:00 PM, Tom "spot" Callaway wrote:
On 09/03/2009 11:35 AM, Hans de Goede wrote:
>> The kernel binary RPM contains this pre-built initrd. The kernel source
>> RPM does not contain the sources necessary to make this pre-built initrd.
>> This makes me rather uncomfortable from a Licensing perspective.
>
> True, but we do provide SRPMS with the sources, if we include a list of
> the SRPMS with the sources, with full NEVR in the kernel rpm as doc,
> wouldn't that be sufficient?
Ehhhhhh. I'm still thinking about that. We don't generally permit other
packages to do that.
Ok let me know which way it is going to be. I'm personally a fan of generating
the initrd on the buildsys, as that way I can get the exact same initrd as
a bug reporter easily. But if you say it has to be generated in %post, I'll start
making the necessary adjustments to new-kernel-pkg and kernel.spec
>> I'm
>> also concerned about it from a security perspective, as these binaries
>> are very likely to be overlooked when security updates are pushed.
>
> We already have that issue with mkinitrd, and will have it when we move
> to generating dracut initrd's in %post too. IOW the security issue will
> always be there, so lets focus on the licensing issue please.
Well, it is less of an issue with mkinitrd, because the user can easily
regenerate it. I do not think this is the same case with the "generic
initrd". Perhaps we could regenerate the generic initrd on the user's
system if any of the binary packages that are used to make it get an update?
Regeneration is as easy with dracut as it is with mkinitrd, actually they
have the same cmdline syntax.
The only extra step required with dracut when using pre-generated images is:
yum install dracut
Regards,
Hans