On Tue, 28 Jul 2009, Matt Savona wrote:
With regards to making these definitions per-repo, it's not strictly necessary. I chose that route simply because I liked the idea of only enabling the behavior when it was absolutely necessary (ie, when I explicitly --enablerepo rubygems). When I push out a yum repo configuration via cfengine, I don't need to worry about updating yum.conf - I just drop the repo conf file and the behavior I want is self-contained.
Fair enough.
Your second point is actually the way I'd prefer to do this, I just don't know how - at least from Yum and other plugin code I've perused. I'd much prefer to just wildcard match in the plugin, expand the package names on a match and add them to the installonlypkgs list - then I never have to deal with modifying the transaction at all. If you have any guidance here, that would be appreciated.
For each item in the per-repo config option you find the match in the list of available pkgs and add that pkg name to the list: base.conf.installonlypkgs
that should be it.
Just because there's 16000 (and growing) packages, doesn't imply they're all installed simultaneously. You're right, it'd get messy. If it were really up to me, I wouldn't have this repository at all - Rubygems work fine all by themselves. Unfortunately, in our environment we use one type of package for everything: RPM. We treat Perl modules the same way, except I don't maintain a complete repository for that. The issue is that we have multiple teams consuming these gems, and everyone requires distinct versions - Rubygems by itself will play along happily - but we don't have that option. There's more to this discussion, but it's best left at: it is the way it is and it can't be changed easily, so we jump through some hoops to accommodate the policy.
Understood. I personally agree with a policy that says there is one kind of package and that is rpm. A single package mgmt system dramatically decreases the mistakes that can be made and places where problems can arise. Additionally it allows for a single audit trail which is nothing to scoff at.
-sv _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
