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