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. -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
