On Tue, Jul 28, 2009 at 10:36 AM, Seth Vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote:
>
>
> On Tue, 28 Jul 2009, Matt Savona wrote:
>
>> Hi All,
>>
>> I maintain a repository within my company of rubygems converted to RPMs. With respect to RPMs and Yum, these packages
>> behave similarly to kernel packages, where some number of versions of a particular package can be installed on the system
>> (the package files never overlap). For example, a system may have rubygem-mygem-1.0.0 and rubygem-mygem-1.0.1 installed
>> in parallel.
>>
>> The current repository contains about 16000 packages - and it's (obviously) not feasible for me to hard code this list of
>> packages in /etc/yum.conf via the installonlypkgs option. What I really needed was the ability to drop a wildcard in the
>> installonlypkgs list, something like 'installonlypkgs=rubygem-*'.
>>
>> I came up with the following plugin, which I don't think is ideal - but it does the trick so far:
>>
>> # ---
>> # I should live here:
>> # /usr/lib/yum-plugins/multiinstallpkgs.py
>>
>> import re
>> from yum import config
>> from yum.plugins import TYPE_CORE
>>
>> requires_api_version = '2.4'
>> plugin_type = TYPE_CORE
>>
>> def config_hook(conduit):
>> config.RepoConf.multiinstallpkgs = config.ListOption()
>>
>> def postresolve_hook(conduit):
>> tsinfo = conduit.getTsInfo()
>> tspkgs = tsinfo.getMembers()
>>
>> def ysp_add_pkg(tspkg):
>> """ True installs a package within a transaction. """
>> tsinfo.addTrueInstall(tspkg.po)
>>
>> def ysp_del_pkg(tspkg):
>> """ Deletes a package within a transaction. """
>> tsinfo.remove(tspkg.pkgtup)
>>
>> for repo in conduit.getRepos().listEnabled():
>> for pkg in repo.multiinstallpkgs:
>> regex = re.compile("^" + pkg.replace("*", ".*") + "$")
>>
>> for tspkg in tspkgs:
>> if (regex.match(tspkg.name) and tspkg.ts_state == "u"):
>> ysp_del_pkg(tspkg)
>> ysp_add_pkg(tspkg)
>> # ---
>>
>> This permits me to have a yum repo defined as:
>>
>> [rubygems]
>> name=Rubygem Repository
>> baseurl=file:///path/to/yum/rubygems/rpms
>> enabled=0
>> gpgcheck=0
>> multiinstallpkgs=rubygem-*
>>
>> Which provides two minor improvements to the behavior of installonlypkgs: 1) it permits me to define what packages I want
>> to be treated as install only via a repo config, rather than the main config, and 2) it permits me to define wildcard
>> matches rather than supplying static package names.
>>
>> What I'm not sure about is the way in which I modify the transaction - by removing and re-adding a package as a true
>> install. I'm wondering, is there a better way? I noticed in depsolve.py, the populateTs method does the following:
>>
>> def allowedMultipleInstalls(self, po):
>> """takes a packageObject, returns 1 or 0 depending on if the package
>> should/can be installed multiple times with different vers
>> like kernels and kernel modules, for example"""
>>
>> if po.name in self.conf.installonlypkgs:
>> return True
>>
>> provides = po.provides_names
>> if filter (lambda prov: prov in self.conf.installonlypkgs, provides):
>> return True
>>
>> return False
>>
>> def populateTs(self, test=0, keepold=1):
>> """take transactionData class and populate transaction set"""
>>
>> for txmbr in self.tsInfo.getMembers():
>> if txmbr.ts_state in ['u', 'i']:
>> if txmbr.ts_state == 'u':
>> if self.allowedMultipleInstalls(txmbr.po):
>> self.verbose_logger.log(logginglevels.DEBUG_2,
>> _('%s converted to install'), txmbr.po)
>> txmbr.ts_state = 'i'
>> txmbr.output_state = TS_INSTALL
>>
>> Is there a way to add my packages to conf.installonlypkgs before the transaction is populated? Or does it not matter,
>> will the effect be the same as what I'm already doing? Or better yet, I know my case is relatively narrow, but would it
>> maybe be feasible to support wildcard matching in installonlypkgs one day?
>>
>> Thanks in advance!
>>
>
>
> First - I don't think it makes sense to have installonlypkgs per-repo - if only b/c it is impacts installed pkgs so it is not clearly a repo-thing. But that's not a big deal.
>
> Secondly, why not have your plugin add items to installonlypkgs based on a wildcard and the nyou don't have to do anything in postresolve at all. installonlypkgs will mark them as trueinstalls on their own.
>
> finally, 16000 installonly pkgs? Really? That sounds like a recipe for pain to me.
>
> let me know if this doesn't make sense.
> -sv
> _______________________________________________
> Yum mailing list
> Yum@xxxxxxxxxxxxxxxxx
> http://lists.baseurl.org/mailman/listinfo/yum
>
Seth,
Thanks for the quick response.
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.
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.
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.
- Matt Savona
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxx
http://lists.baseurl.org/mailman/listinfo/yum
