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

Re: mock buildroot definitions

> 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.

not really - just have the specfile in the tree, edit the spec file
 rpmbuild --a-bunch-of-path-definitions -bb foo.spec 
then createrepo the dir.

I do it now for something other than mock and it's not really much more
work than a cvs commit.

> 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.

not nicely. If we were to do that we'd have 3 different versions of the
group code in place right now and I'm sure we'll have more as we go
forward. It'd just make for cumbersome, unmaintained code in yum and I'd
rather not have that if we can avoid it.

> 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.

and the reason we like having it centrally stored is to help all the
extras packagers who are testing their builds using mock on their home
machines. This way if we change what is in the base of the buildroot we
don't have to propagate the files and they have to get to the repo in
order to use buildsys-macro to get the %{dist} tag.

I'm open to other suggestions, though.

In fact - to accommodate some of these ideas I've added a MockTodo page
in the fedoraproject.org wiki.

Please put down some things you want to see in there.




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