Re: [RFC PATCH v3] kbuild: fix error when building from src rpm

[Doug Ledford <dledford@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

On 6/5/2013 6:17 AM, Marciniszyn, Mike wrote:
> I sent a different version today that used %defines for each arch,

I didn't look through the original patch (especially since you said you
are sending a new one).  However, please keep in mind that we need to
either put firmware in a kernel version specific directory or split it
off to a separate patch.  Otherwise you can't install more than one
kernel package at a time.

> but this idea is better and doesn't create a maintenance issue.  The
> scope would be kbuild wide so I assume that the cc list needs to
> expand?
> 
> Also, I will also want to add a new package to create a kernel-devel
> package and will be submitting patch for that shortly.
> 
> Thanks, Mike
> 
> 
>> -----Original Message----- From: Michal Marek
>> [mailto:mmarek@suse.cz] Sent: Wednesday, June 05, 2013 5:54 AM To:
>> Marciniszyn, Mike Cc: linux-kbuild@vger.kernel.org; Doug Ledford 
>> Subject: Re: [RFC PATCH v3] kbuild: fix error when building from
>> src rpm
>> 
>> On 4.6.2013 22:12, Marciniszyn, Mike wrote:
>>> Sorry for the confusion with the patch.
>>> 
>>> The latest version I've changed to an RFC because of some
>>> testing issues I've encountered.
>>> 
>>> The /sbin/installkernel doesn't behave very nicely when
>>> INSTALL_PATH is modified on RH6.4.
>> [snip]
>>> I'm seeing when spec file tries to do its own install...
>>> 
>>> I'm open to suggestions for making this part of the spec file
>>> portable and the src RPM usable.
>> 
>> You could introduce a new Makefile target, say image_name, that
>> would simply print the image name after including the arch
>> Makefile. Then in the spec file, you would simply do
>> 
>> KBUILD_IMAGE=$(make -s image_name)
>> 
>> I think that this target would be a useful addition to the already
>> existing kernelversion and kernelrelease targets. And BTW, we could
>> use make -s kernelrelease in the specfile as well, instead of
>> hardcoding the value there.
>> 
>> Michal



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]