Adding packages to buildroot directly from updates-testing

Jesse Keating jkeating at redhat.com
Thu Dec 16 20:28:35 UTC 2010


On 12/16/10 12:22 PM, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 12:14 -0800, Jesse Keating wrote:
>> On 12/16/10 10:29 AM, Matt McCutchen wrote:
>>> (BTW, it seems that a custom tag would generally be better than a
>>> buildroot override for the reasons we are discussing even if there's
>>> only one dependent package, unless that would put some kind of strain on
>>> the infrastructure.  Is a request for a custom tag more work than a
>>> buildroot override request for the releng team?)
>>>
>>
>> A custom tag would slow things down considerably.  When doing a
>> buildroot override, the newRepo task can take the pre-existing repodata
>> into account when calling createrepo and be done fairly quickly (a few
>> minutes of actual createrepo time).  A new custom tag would require
>> creating fresh repodata from scratch which can take an hour or more of
>> actual createrepo time.
> 
> I assume you're referring to "createrepo --update"?  How hard would it
> be to seed the new tag with the repodata of one of the tags it inherits?

Yes, I'm referring to --update (and --skip-stat).  Seeding the new tag
with one of the tags it inherits would take some code in koji.  I don't
know how much code it would take, but it would take code.

> 
> An alternative approach would be to mirror the semantics of tag
> inheritance by having builds use multiple yum repositories, possibly
> with priorities, instead of explicitly computing the resulting repodata
> for every tag.  Would that be feasible?
> 

Again it would take code, and quite a bit of logic to figure out what
packages are blocked in various tags to make sure the repo config files
used exclude the right packages, etc...

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating




More information about the devel mailing list