Its common on RedHat platforms to use repos to install certain packages, and keep them disabled. This will insure that no packages are used from that repo during events such as automated updates.

I think a better solution would be to use custom repos that are under your full control, rather than rely on enabling and disabling repos. Keep “facter” and all dependancies in a custom repo, install/update from there.

I’m amenable to this ticket if it really is about enable/disable; but the description of the ticket focused on a quick enable/disable stage while evaluating one resource, which we can’t really do right now.

Is just the enable/disable sufficient?

Sorry Luke, I don’t really understand your meaning.

My point in the original feature request was to allow the ‘yum’ provider to have the “—enablerepo” option passed to it on a ‘package’ provider request it a manifest.

So for example, “facter” and “puppet” appear in the “epel-testing” repo first and may take weeks to make it into “epel”. “epel-testing” is a disabled repo by default due to the possibly unstable nature of packages contained in it. However if i require “facter” from “epel-testing” presently i would either have to do it manually on hundreds of systems (painful), write a ‘exec’ to handle it (messy) or enable the “epel-testing” repo system wide (dangerous).

The original example would result is a yum command line like this:

yum -y —enablerepo=epel —enablerepo=epel-testing install facter

Which would allow for “facter” to be installed from “epel-testing” if the latest version is available from there.

Another good example is the “dag” repo, it has 1000’s of packages, some really scary and some really useful, but the “dag” repo is not enabled by default.

package { “ocrad”: ensure => installed, enablerepo => “dag”, disablerepo => “rpmfusion” }

would result in

yum -y —enablerepo=dag —disablerepo=rpmfusion install ocrad

This would be a very useful feature for those of us on systems with ‘yum’ as the package manager where enabling and disabling repo’s is common practice.

I didn’t understand what you meant at first — I didn’t realize that you wanted to be able to enable/disable while running yum.

I’m sure that would be useful, but it’s also entirely non-deterministic. How do you know, going backward, which repo a given package was installed from?

This strikes me as pretty bad management practice, and it can be relatively easily obviated by just maintaining your own repo, in which you stick the packages from the various repos that you want.

i do maintain my own repo of my own signed packages, along with my own testing repo which is disabled by default and this feature would allow me to use it from puppet.

i do not see the sense in maintaining my own repo of select packages and all their dependencies from a reliable repo like EPEL.

i may be wrong here but after many year of maintaining redhat systems it is regular practice enabling and disabling repos as needed to keep the base system as pure as possible.

so my own repos are ‘custom’ and ‘custom-testing’, the ‘custom’ repo is enabled by default and the ‘custom-testing’ repo is disabled following the typical yum repo practices used by most repos.

Just for example, all these repos would not be & should not be enabled.

http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/10/i386/ http://download1.rpmfusion.org/free/fedora/updates/testing/10/i386/ http://dev.centos.org/centos/5/testing/i386/

I think this would be a good addition to the yum package provider – it’s not uncommon that you want one package from some unstable/experimental/whatnot repo, without running the danger of pulling others in.

The fact that it’s not possible to track from which repo a package was installed is really a problem in the underlying tools; it would be great if we could make hte repo show up in hte logs from the yum provider any way (would require a small tweak to yumhelper.py and the yum provider AFAIK)

I am not concerned about logging where a package comes from, however it would be nice. The yum implementation on RHEL/CentOS does not log the source repo currently.

tail -1 yum.log¶

Jun 04 15:09:11 Installed: dnsmasq.x86_64 2.47-0.1.el5

If you are going to log the source repo of the package then you should also log all dependencies dragged in by yum and the repo’s they came from. Again, nice to have but not a deal breaker.

Whatever are the limitations of yum, the bottom line is that it would make puppet that much more useful and less combersome to use if it could allow passing of the —enablerepo= command line parameter to yum directly through the yum provider.

We found this bug report through looking for a solution for exactly that requirement.

Thanks.

I guess my main problem with this ticket is that it further differentiates the model of yum from other package providers. Is this a general modeling problem that we can apply to the base type? If not, is it a subset of one? Will other package providers need this kind of functionality?

apt-get has the “-t” which allows you to do a similar thing. the thing is that puppet provides an ‘type’ to create and manage yum repositories, “yumrepo”, so adding enablerepo support to the package type provides a more complete solution for applicable platforms.

From man apt-get.

   -t, --target-release, --default-release
       This option controls the default input to the policy engine, it creates a default pin at priority 990 using
       the specified release string. This overrides the general settings in /etc/apt/preferences. Specifically
       pinned packages are not affected by the value of this option. In short, this option lets you have simple
       control over which distribution packages will be retrieved from. Some common examples might be -t ´2.1*´ or
       -t unstable. Configuration Item: APT::Default-Release; see also the apt_preferences(5) manual page.

Agreed. I think a “enablerepo” on the package provider would be VERY useful. I typically keep all yum repositories disabled, and only enable when I install certain packages. I don’t see any other way to do this with puppet.

First, this is really a feature request, not a bug, and ought to go in a feature release, not a bug release.

Second, the best idea I came up with would be to have a “repositories” attribute on the Package type, with the semantics that:

1) If it’s left undefined, ‘’, or an empty array, the behavior would be unchanged 2) If it’s a non empty string it’s treated as an array consisting of that one string 3) Otherwise the repos specified are passed as command-line arguments, e.g. repositories => [foo,bar]

* On apt gives "-t foo -t bar"
* On yum gives "--disablerepo=* --enablerepo=foo --enablerepo=bar"

What do people think of that?

I would like to see other yum options allowed in addition to enablerepo/disablerepo. For example,

—nogpgcheck To install unsigned packages on a case-by-case basis versus at a repository level groupinstall Need to install package groups downgrade Some packages can require a downgraded version of a dependency clean Adding a new repository or having a bad mirror and/or cache may require a rebuilding the cache upgrade Trigger a full update instead of package by package update

This may be a separate ticket, but I wanted to add the comments.

groupinstall Need to install package groups

About that option there have been recently some discussion around. The problem is a bit in the semantic that groupinstall introduce, as groupinstall can’t really be seen as a single package resource. Read more about that on the mailinglist.

—nogpgcheck To install unsigned packages on a case-by-case basis versus at a repository level

could be added like the enable enable/disable repo one.

downgrade Some packages can require a downgraded version of a dependency

Imho this one should be autohandled if you specify via ensure a version which is lower than the current installed one. If not, a ticket should be filed.

clean Adding a new repository or having a bad mirror and/or cache may require a rebuilding the cache upgrade Trigger a full update instead of package by package update

These 2 are cleary options that affect the whole system and not only a single resource. Hence, it would be wrong to have them in the package provider and I think they are best suited to be used in an exec. Besides a lot of confusion and possible problems I don’t see any advantage to have them within the package provider.

Markus Roberts wrote:

Second, the best idea I came up with would be to have a “repositories” attribute on the Package type, with the semantics that:

1) If it’s left undefined, ‘’, or an empty array, the behavior would be unchanged 2) If it’s a non empty string it’s treated as an array consisting of that one string 3) Otherwise the repos specified are passed as command-line arguments, e.g. repositories => [foo,bar]

* On apt gives "-t foo -t bar"
* On yum gives "--disablerepo=* --enablerepo=foo --enablerepo=bar"

What do people think of that?

A “repositories” attribute would be the most generic for both yum and apt.

Its not ideal for yum users who are used to being able to enable or disable one repo in addition to the default enabled ones however apt doesn’t have an equivalent to “disablerepo” so yum users will need to list ALL required repos to satisfy dependencies for the given package/s.

e.g. repositories => [ os, updates, epel, epel-testing ]

I can live with that.

Is yum-tmprepo something that can be used in this feature request?

From the package description:

       : This plugin adds the option --tmprepo which takes a url to a .repo file
       : downloads it and enables it for a single run. This plugin tries to ensure
       : that temporary repositories are safe to use, by default, by not allowing
       : gpg checking to be disabled.

I can’t see I’ve seen alot of people using this plugin before, but for this case it acutally seems useable.

What do you guys think?

Tore L. wrote:

Is yum-tmprepo something that can be used in this feature request?

From the package description:

       : This plugin adds the option --tmprepo which takes a url to a .repo file
       : downloads it and enables it for a single run. This plugin tries to ensure
       : that temporary repositories are safe to use, by default, by not allowing
       : gpg checking to be disabled.

I can’t see I’ve seen alot of people using this plugin before, but for this case it acutally seems useable.

What do you guys think?

It would make more sense to utilize the —enablerepo flag of yum rather than introducing another package requirement for this type (as it’s built in).

The more generic solution was requested in #915 but as stated above maybe it makes no sense to allow to override every option.

Actually, that doesn’t work, ignore it for the moment – I’m working on a better one.

Just tested this patch and it seems to work for enablerepo at least.

This patch is a little more robust than my private patch I have been using for a long time to accomplish the same thing.

Hi Nathan,

yes, it doesn’t do disablerepo, but it wouldn’t be hard to add it in. There’s a slight subtlety about ordering, but I did the work on the yumhelper that enables it, just not the work in the ruby. The ruby pattern would pretty much follow my existing work for the enablerepo, though. It’s possible that what should actually happen is that you do the disable by doing a “–” and pick that up in the python. This allows you to do things like:

enablerepo => “–*,myrepo”

or

enablerepo => “*,-myrepo”

Cheers

MBM

Nigel,

Your status change seems spurious. Puppet already has options that are applicable only to single backend handlers in several places, so mentioning apt-get -t and using that as an apparent excuse for changing the status away from Accepted seems a little disingenuous. Not only that, but doing it when there’s a working, if slightly nasty, patch that’s been soundly ignored to do this attached to the ticket just makes you seem plain rude.

Quite frankly, I and other people will continue to need this feature out of puppet, because we don’t want yum to pull in half the world by magic in normal sysadmin operation. I guess that this means that those of us who want this feature will continue to need to patch puppet to make it do the right thing and work for us because things are being “shoe-horned into the package type”.

For the record, too, the fact that you’ve totally ignored the patch (I don’t mind it being rejected, I do mind it being ignored – it’s common courtesy to say “thanks but no thanks” if you don’t want it, and explain why you don’t like it) in this case is likely to make me just maintain my own patches in future without bothering to share them back ever. You may consider this a good thing – I think that’s the death of an “Open Source” project.

Cheers

MBM

Hi Matthew

I think your assessment of Nigel’s update is a bit harsh but that aside I am happy to see some discussion on the patch. I personally think we’re overloading the type with a Yum specific option – and once you open that flood gate it’s hard to stop the flood…

If you’d like your patch reviewed can you please take a look at our Development Lifecycle (https://projects.puppetlabs.com/projects/puppet/wiki/Development_lifecycle). The primary things you’ll need to do is sign a CLA and then if you could send your patch to the puppet-dev list for review that’d be awesome.

Thanks for your contribution.

Nigel Kersten wrote:

apt-get -t is not the same as —enablerepo for yum.

The former simply adjusts priorities amongst active repositories, the latter temporarily enables a disabled repository.

Those are very different things.

I’m not feeling particularly good about trying to shoe-horn this into the package type. Does any other platform have something like this?

I’ve just gone through all the package providers in next and have come up with a few similar situations, based on manpages I was able to find online.

• fink can enable/disable “trees” (i.e. unstable/stable) with complex expressions: fink usage
• up2date can specify —channel (is this only for —installall?): man up2date
• urpmi can specify a media repo name with the —media option: man urpmi
• zypper can specify the repository name (repo:package): zypper usage

There are a bunch of others that can specify the repository by URL, overriding their config file, either by an argument or environment variable. The gem, pip, openbsd, freebsd and ports providers all implement this with the “source” package property while blastwave and pkgutil don’t, but probably should.

Thank you for the research Dominic.

Maybe a “repository” setting does make sense then.

Matthew Byng-Maddick wrote:

Nigel,

Your status change seems spurious. Puppet already has options that are applicable only to single backend handlers in several places, so mentioning apt-get -t and using that as an apparent excuse for changing the status away from Accepted seems a little disingenuous. Not only that, but doing it when there’s a working, if slightly nasty, patch that’s been soundly ignored to do this attached to the ticket just makes you seem plain rude.

I’m sorry if that’s how it came across, but moving it away from Accepted doesn’t mean I’m rejecting it.

The move to “Needs More Information” indicated that I didn’t think we had enough information scoped out to hand this to a developer, not that I’m rejecting it. I did so at the same time as I asked a question about other package types, which I thought made it clear I was looking for more information to scope the work.

If it was being rejected, the status would have moved to Rejected.

Quite frankly, I and other people will continue to need this feature out of puppet, because we don’t want yum to pull in half the world by magic in normal sysadmin operation. I guess that this means that those of us who want this feature will continue to need to patch puppet to make it do the right thing and work for us because things are being “shoe-horned into the package type”.

For the record, too, the fact that you’ve totally ignored the patch (I don’t mind it being rejected, I do mind it being ignored – it’s common courtesy to say “thanks but no thanks” if you don’t want it, and explain why you don’t like it) in this case is likely to make me just maintain my own patches in future without bothering to share them back ever. You may consider this a good thing – I think that’s the death of an “Open Source” project.

The patches aren’t suitable to be merged yet. They’re lacking tests, and it wasn’t clear we had consensus on an appropriate cross-platform parameter name, and as my question showed, I wasn’t sure whether there was an equivalent option across a large subset of our providers.

Nigel Kersten wrote:

I’m sorry if that’s how it came across, but moving it away from Accepted doesn’t mean I’m rejecting it.

The move to “Needs More Information” indicated that I didn’t think we had enough information scoped out to hand this to a developer, not that I’m rejecting it. I did so at the same time as I asked a question about other package types, which I thought made it clear I was looking for more information to scope the work.

I appreciate what you’re saying, and James is probably right that Ben’s post was a little harsh. However I think you guys need to consider that this is a key aspect of how many of us have to manage our RPM based systems. RedHat simply doesn’t cover everything that is needed, and some software just can’t be left at the release versions they provide. As others have stated, we also can’t just leave them enabled for a stray install or update/upgrade to wreak havoc on production systems.

This ticket has been open for nearly TWO YEARS. That’s two years of our hacking around this notable limitation. That’s two years of the ticket status suggesting it was about to get implemented – and then be pushed off because suddenly you guys weren’t sure or decided this or that piece of information wasn’t available in the ticket yet. It’s been very frustrating. If it hadn’t been for the number of notifications on this one I wouldn’t have even bothered to click through because I just assumed the updates were you guys pushing it off again.

Take that into account when you read Ben’s post. While objectively Ben’s post had a harsh tone, I think if you consider the position of the users struggling with this problem it’s not really surprising.

I do understand the frustration, but if you look through the history of this ticket it hasn’t had a clear path forward. There was a lot of chatter back and forth before the use case was made clear, and we’ve had somewhat unrelated comments and requests sprinkled through it.

If this was a complete patch including tests, it would have been merged by now.

I do think that accusing us of killing an “Open Source” project is unwarranted hyperbole, but the various people commenting on this ticket (and I include myself) should have made it clearer that the code as attached was lacking, and we would have made faster progress on getting it merged in, instead of leaving things in a confusing limbo.

I would like to reboot this ticket thread in a more productive direction.

To those of you who require this feature, are any of you up for writing a test suite for it?

If you’re interested in learning to write tests for Puppet code but don’t feel confident doing it yet, please speak up too, and I’ll make sure someone is available to give help.

Nigel Kersten wrote:

I would like to reboot this ticket thread in a more productive direction.

Well – my intent there was productive, in terms of promoting understanding. Sometimes when you’re not the one impacted it can be hard to understand the frustrations that come through from the other side.

To those of you who require this feature, are any of you up for writing a test suite for it?

If you’re interested in learning to write tests for Puppet code but don’t feel confident doing it yet, please speak up too, and I’ll make sure someone is available to give help.

I think I would fit both of those. I’m comfortable (mostly) with Ruby and with writing tests, but I haven’t done anything the core puppet code. I also have very little time over the next week and a half. If nobody else speaks up before then I’ll try to put this on my plate. It’s as good a place as any to start.

Hi Nigel and James,

Thanks for your considered replies. I’m sorry if my initial update came across as harsh, but I hope you can understand my frustration at finding a ticket relating to the exact problem I needed to solve that was 2 years old, doing the work to write the patch, attaching it to said ticket, and then seeing the first person from any kind of puppet committer team changing the status away from “Accepted” – not pointing me in any kind of direction as to why they were ignoring the patch, but apparently just ignoring its existence.

Yes, it’s very nasty – it’s a bit of a quick hack, but it certainly points the way – I wasn’t expecting it to just be merged – far from it, but the cat that I’ve put amongst the pigeons above has had the desired effect.

Mark: it’d be great if you can take this and do it properly (I also have very little time to work on something that I now know works for me) – there are a couple of changes that need to be made. In particular, you probably want to change it from enablerepo to just “repositories” or some similar generic name, and then do the add and disable in one go – this allows you to be order dependent (as yum itself is). I merely shared the patch to ease the 2 year-old frustration for anyone who came to look at this ticket – it was far from polished and finished and appropriate for merging.

Cheers

MBM

Mark Bainter wrote:

Nigel Kersten wrote:

I would like to reboot this ticket thread in a more productive direction.

Well – my intent there was productive, in terms of promoting understanding. Sometimes when you’re not the one impacted it can be hard to understand the frustrations that come through from the other side.

You were completely productive Mark, and as Matthew says, thank you for a considered reply. We’re all in the same community here :)

Matthew Byng-Maddick wrote:

Hi Nigel and James,

Thanks for your considered replies.

No worries Matthew. We’ll get this sorted.

Any update?

Just to add some weight to this, We’ve just encountered a scenario that would also benefit from being able to pass through enablerepo and disablerepo through to the Yum provider. In this case, trying to install “vlc” on RedHat, it requires several packages from rpmforge and updates but this clashes with stuff that we have in our own repos. The only way we’ve managed to get yum to resolve all it’s dependencies for this package is to disable our internal repos and use yum —disablerepo “*” —enablerepo base,testing,rpmforge. We are currently forced to do this with an exec, which is not nice.

Surely passing through valuable yum features like this to the provider isn’t a bad thing?

We still plan on doing #4113, but until it’s figured out exactly what that will look like we’re planning on implementing this ticket, especially since it’s not necessarily incompatible with some of the visions for #4113.

We’ll definitely take a look at the code that’s been submitted so far when we’re looking at this ticket.

Hi Jacob,

I’ve put “I agree” into the bottom of the box, and Redmine says “Contributor Licence Accepted”. Is that all I need to do, or do you still need a physical copy?

Cheers

MBM