[Yum-devel] repo priorities

[Florian Festi]

seth vidal wrote:
> On Thu, 2007-09-06 at 15:37 -0400, seth vidal wrote:
>> On Thu, 2007-09-06 at 08:26 +0200, Tim Lauridsen wrote:
>>>>   
>>> +1, for inclusion in core.
>>> something like
>>> cost=5
>>> in the repo file.
>>> the default value for cost should be '10' or something like that.
>> So here's an interesting twist.
>>
>> cost is really an attribute of a package. Since there's nothing saying a
>> package in repodata has to be at the same url as the repo. So if we're
>> working along those lines we make cost be listed in the repo config but
>> we add it as an attribute of all the pkgs in that repo. This opens up
>> new angles for plugins.
>>
>> so arguably a plugin could do:
>>
>> for pkg in allpkgs:
>>     if pkg.basepath.startswith(ftp://):
>>         pkg.cost = 80000
>>     ...
>>
>> it also makes comparisons in the future easier:
>>
>>    if all other things about these pkgs are the same:
>>      pkg.cost > pkg.cost...
>>
>> What do y'all think? Does that make sense?
>>
> 
> slight hang up here - to make it functional as an attribute of a package
> it has to be persistent. We CAN dynamically create pkgs from the
> sqlitesack and they won't necessarily persist. It seems like we'd want
> to keep a cost dictionary in each repository/sack that let's us re-add
> that attribute if we make a new object on the fly. Then if we're going
> to do that it would make more sense to have a generic ability to add
> attributes to a package that would persist w/i the session independent
> of the destruction/construction of any given package object. Obviously
> the values should not persist across destruction/construction of a
> packageSack  but it's an interesting concept to me.

Sorry for my late reply, but...

with the current code this is only partially true. In most cases pkg objects 
are reused now. IIRC there are a few cases left where we create new pkg 
objects. Instead of creating some parallel data structures if would be 
easier and much cleaner to fix that last few places where we create pkg 
objects unregulated.

Having persistent pkg objects could simplify a lot other code, too.

Florian