mock buildroot definitions

[Jeff Sheltren]

On Mar 28, 2006, at 11:05 AM, seth vidal wrote:

> Hey,
>  So it was brought up a while ago that due to the changing nature  
> of the
> comps.xml format that we should not rely on it for the buildroot
> installations in mock. The idea a while back was to just have a
> 'buildroot' rpm that required all the stuff that would normally be in
> the comps.xml group. Then we could just install that rpm and it  
> pulls in
> the rest of the buildroot components.
>
> What do folks think? Worth going through the process to do it?
>
> -sv
>

I still don't like the idea of using an RPM to accomplish this.

Having the buildroot packages in an editable text file makes it  
extremely easy to see what is being installed, and also it simple to  
add or remove packages if you have the desire/need to do so.  If this  
information were stored in an RPM, you'd have to install the SRPM to  
get at the spec file which would contain this information (I guess...  
depending on how the package were to be implemented).  To add/remove  
a package to/from the buildroot group would involve rebuilding the  
RPM and then uploading it to the server.

So, ideally (for me, anyway), the group package lists should be  
stored in some sort of editable file, be it xml, plain text, or  
whatever.  Even if the comps format is changing, wouldn't it be  
possible to keep the current group code in place within yum?  It  
could even be called --mockinstall if you need a way to separate it  
from the "new" groups format.

Another idea would be to include these package lists inside of the  
mock package.  For example, a config setting in /etc/mock/ 
whatever.cfg would allow you to list a file which contains a list of  
the build group.  Of course, if you have a large number of machines  
running mock (as in a plague setup) you'd probably want this config  
stored in a central location so there is no need to modify each  
builder individually.

-Jeff