#for import-comps handler (currently disabled) #from rhpl.comps import Comps
I've ported this to FC6 yum.comps to make it work for the buildroot list, but it's only rudimentary, because I didn't find anything about the "biarchonly" attribute. The "basearchonly" attribute, on the other hand, is not evaluated by yum.comps. Plus, I couldn't find any groupreq and metapkg support in yum.comps either.
On Tue, 24 Apr 2007 12:24:22 +0200, Michael Schwendt wrote:
#for import-comps handler (currently disabled) #from rhpl.comps import Comps
I've ported this to FC6 yum.comps to make it work for the buildroot list, but it's only rudimentary, because I didn't find anything about the "biarchonly" attribute. The "basearchonly" attribute, on the other hand, is not evaluated by yum.comps. Plus, I couldn't find any groupreq and metapkg support in yum.comps either.
If the patch in this thread has been noticed and considered insufficient, please say so. If it has not been seen yet: ping
On Tue, 2007-04-24 at 12:24 +0200, Michael Schwendt wrote:
#for import-comps handler (currently disabled) #from rhpl.comps import Comps
I've ported this to FC6 yum.comps to make it work for the buildroot list, but it's only rudimentary, because I didn't find anything about the "biarchonly" attribute. The "basearchonly" attribute, on the other hand, is not evaluated by yum.comps. Plus, I couldn't find any groupreq and metapkg support in yum.comps either.
So, I'm not actually sure what the import-comps command is actually used for[1], but as for some of the other things.
biarchonly, basearchonly, groupreq and metapkg are all elements of the old comps format supported by rhpl.comps and not the new comps format supported directly by yum.
Jeremy
[1] It looks like the idea is to be able to store the comps info directly in the buildsys so that a comps file could then just be spit out. But I'm not 100% sure there. And it raises some questions on how it works with other parts of the process around comps like translations
On Monday 14 May 2007 11:03:00 Jeremy Katz wrote:
[1] It looks like the idea is to be able to store the comps info directly in the buildsys so that a comps file could then just be spit out. But I'm not 100% sure there. And it raises some questions on how it works with other parts of the process around comps like translations
Not quite right. The comps thing is somewhat of a historical thing with how mock populates the default buildroot. We've created the idea of groups within koji, like the 'build' group, that is used to populate the buildroot. Koji could have the ability to 'import' a written out comps file to get the grouping information, however I've just been doing it by hand since the group is fairly small. It has nothing to do with the comps used for composing a distribution.
On Mon, 14 May 2007 11:13:34 -0400, Jesse Keating wrote:
On Monday 14 May 2007 11:03:00 Jeremy Katz wrote:
[1] It looks like the idea is to be able to store the comps info directly in the buildsys so that a comps file could then just be spit out. But I'm not 100% sure there. And it raises some questions on how it works with other parts of the process around comps like translations
Not quite right. The comps thing is somewhat of a historical thing with how mock populates the default buildroot. We've created the idea of groups within koji, like the 'build' group, that is used to populate the buildroot. Koji could have the ability to 'import' a written out comps file to get the grouping information, however I've just been doing it by hand since the group is fairly small. It has nothing to do with the comps used for composing a distribution.
Well, I used the patched koji to import the package-set for the minimal buildroot, which was a requirement for getting a first test-build done.
On Monday 14 May 2007 11:52:12 Michael Schwendt wrote:
Well, I used the patched koji to import the package-set for the minimal buildroot, which was a requirement for getting a first test-build done.
Right, there is a little known way to get by without importing, using 'koji call' to call a specific API call. There is currently not a cli command to create a group, so I have to use a call to call the groupListAdd API call to create the group, then standard cli commands to add things to said group.
Jeremy Katz (katzj@redhat.com) said:
biarchonly, basearchonly, groupreq and metapkg are all elements of the old comps format supported by rhpl.comps and not the new comps format supported directly by yum.
groupreq still exists in current comps. Perhaps that should be 'fixed'?
Bill
buildsys@lists.fedoraproject.org
-
Bill Nottingham -
Jeremy Katz -
Jesse Keating -
Michael Schwendt