Re: Needed: An easier way to build a subset of kernel packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jarod Wilson wrote:
> Chuck Ebbert wrote:
>> Jarod Wilson wrote:
>>> Dave Jones wrote:
>>>> On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote:
>>>>  > Dave Jones wrote:
>>>>  > > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote:
>>>>  > >  > I was thinking about adding something like this to the .spec file
>>>>  > >  > at the beginning:
>>>>  > >  > 
>>>>  > >  > %define allowup 1
>>>>  > >  > %define allowsmp 1
>>>>  > >  > %define allowpae 1
>>>>  > >  > %define allowxen 1
>>>>  > >  > %define allowdoc 1
>>>>  > >  > %define allowdump 1
>>>>  > >  > %define allowheaders 1
>>>>  > >  > %define allowdebug 1
>>>>  > >  > 
>>>>  > >  > Then, after all the automatic enable/disable of various options is done,
>>>>  > >  > turn off everything that's not allowed.
>>>>  > >  > 
>>>>  > >  > This would make it much easier to change what gets built.
> [...]
>>>> But I've not objection to making it easier for people who don't follow
>>>> my workflow and do things differently.
>>> Rather than wasting Chuck's time implementing this, what say a
>>> lower-level grunt like myself try to implement something along these
>>> lines? :) I've got a few ideas on how to do it using either %bcond or
>>> %with{,out}...
>> You understand rpm better than I do, so go for it. I'd use Dave's method
>> but an RPM is so much more convenient...
> 
> Cool, I'm on it...

There are a few ways to approach this...

The minimalist approach that comes to mind is to make all the %define
build* bits all set to 1/enabled by default, and only flip them to
disabled where appropriate, so they'd be equivalent to your allow* idea,
in that if you disable them at the top of the spec, they'd stay disabled.

The all-out approach is to implement support for --with/--without on the
rpmbuild line. Nice to have, but adds complexity/legibility issues to
the spec (not that this isn't already a very hard to read spec...), and
I'm not sure if I'd actually use it or not.

Any strong preference for one route or the other? (Or yet another)

-- 
Jarod Wilson
jwilson@xxxxxxxxxx


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list

[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux