Matt Savona <matt.savona@xxxxxxxxx> writes:
> 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 -
The simple way to do this should be deceptively easy, something like:
def postreposetup_hook(conduit):
base = conduit._base
pkgs = base.pkgSack.returnPackages(patterns=['rubygems*'])
pkgnames = [pkg.name for pkg in pkgs]
base.conf.installonlypkgs.extend(pkgnames)
...of course this kind of sucks in that postreposetup is called
multiple times if you use --enablerepo etc.
And you'll need to change base.conf.installonlypkgs into a set(), or
performance will suck at 16k items, and you'll want to have
installonly_limit == 0 or performance will suck there too.
> 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.
Well I would say it's "not recommended" to try doing the above, or to
create 16k pkgs with versions in their name so you can install
multiple versions at once (which is probably better for a few
reasons¹).
Personally I would recommend that you try as hard as possible to have
people using the same versions, and heavily document the
exceptions. Then have versioned pkgs for just those exceptions, like
compat-rubygem-blah-1.2.3-1.2.3-4.noarch or whatever.
This means you're package count can grow without having the multiple
installed pkg count automatically grow as well ... and gives some
visibility into which packages need separate versions (and for how
long).
¹ For a start the only thing that's installonly atm. is the kernel,
so there is no testing for weird cases you might hit like
"yum install A B" where A and B depend on different specific versions
of C (which is installonly).
--
James Antill -- james@xxxxxxx
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxx
http://lists.baseurl.org/mailman/listinfo/yum
