Subject: | |
From: | |
Reply To: | |
Date: | Thu, 16 Jun 2011 14:45:48 +1000 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Does anyone have a howto or similar on building spec files?
I've got my Xen packages built for SL6, but I'm trying to reverse
engineer the SL6 kernel SRPM to figure out how its all done.
My idea is to basically remove linux-2.6.32-131.2.1.el6.tar.bz2 from the
SOURCE directory and replace it with my linux-dom0-2.6.32.40.tar.bz2 and
alter the kernel.spec to suit.
Is there a better way or someone wiser than me have any hints on this
process?
--
Steven Haigh
Email: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
On 15/06/2011 4:44 AM, Troy Dawson wrote:
> On 06/13/2011 11:06 PM, Steven Haigh wrote:
>> On 14/06/2011 9:33 AM, Shawn Thompson wrote:
>>> There's already a bunch of "contrib" repositories for EL packages
>>> (repoforge, atrpms, etc), maybe talk to them?
>>
>> I was thinking about this - but a properly working Xen configuration
>> requires a new kernel RPM. I was looking at packaging the kernel as -
>> say - kernel-dom0-whatever and including that.
>>
>> I believe the policy of other repos do not accept kernel RPMs. I am
>> happy to be corrected if this is not correct!
>>
>
> For SL6 we have moved away from having our own contrib repository. We're
> trying to keep it that way by utilizing the EPEL, rpmforge, elrepo and
> atrpms repositories. But that doesn't mean you cannot setup your own
> repository and tell people about it.
>
> As far as I know, none of the other repo's have kernels in them, other
> that elrepo, which has one along with very strong warnings that the
> kernel is not supported.
>
> I believe one of the reasons why these repo's do not have kernels is
> because of the commitment.
> The kernel is a very complicated package, constantly changing, needing
> security and bug fixes.
> Scientific Linux is also a long term enterprise release, each major
> release lasts 7 years.
> To maintain a kernel in a repo means you have to deal with security and
> bug fixes for 6 to 7 years.
>
> Troy
|
|
|