Issue #5319 has been updated by Nick Moffitt.
Nigel Kersten wrote: > The apt provider doesn't do what #4067 describes Nick. I think we're > talking past each other without understanding what the other is > saying. My reading of #4067 is that when any resource X depends on package A, and package A's actual package file depends on package B, puppet detects this somehow and adds the dependency to the chain (autocreating a resource?). So now X ultimately depends on B. This dependency resolution sort of falls out of using apt (or perhaps yum) as the provider to install A, no? I'm not actually interested in dependency resolution (which apt does all by itself, albeit not in a way that puppet seems to be informed of yet). I'm interested in <code>ensure => installed</code> becoming <code>ensure => selected-for-later-installation</code>. My contrived example of the conflicts/replaces cycles comes from the fact that puppet seems to have zero support for concepts like "supersedes" or "replaces" or "conflicts" in its package dependency model. This means that it will happily remove a package that it installed earlier in a run, merely as a side-effect of installing another package that conflicts+replaces it. This is simply one circumstance in the possible package relationship graphs where a blind <code>apt-get -q -y install *foo*</code> can have unhappy results. It's one of a host of reasons why certain well-behaved packages currently require installation chaperoning: "Wait, it wants to remove *what*? No! Abort! Let's re-think this metapackage, here." Am I misreading #4067? > > Packages will have bugs. I need these buggy packages to be > > chaperoned during install. > > I do understand what you're saying here. Personally I would always > just fix the packages and insert those patches into my build system, > but that may not be everyone's approach. Yes, and we do this where we can. That means we then have to become maintainers of the package, watching like a hawk for security updates because we've opted out of the distro updates, keeping it on hold because we can't upgrade to the version upstream. Sometimes it's less work in the end to just have a human being actually watch the installation and keep it from running amok. > I'm just trying to work out if there is a larger problem here that we > can address that will solve your use case as described. The larger problem is that invoking the -y flag to apt-get is simply a bad idea in general. Consider: http://snowulf.com/2008/12/04/truly-non-interactive-unattended-apt-get-install/ Which tells us that for a while at least mysql would install with its root user wide open. Preseed files can only get you so far in a case like this, and maintaining custom packages of mysql sounds like someone else's idea of fun rather different from my own. My custom provider manages to do *precisely* what I need, barring the reporting requirements (for which I intended to write a nagios check) or any bugs. ---------------------------------------- Feature #5319: ensure => selected for packages requiring interactive installation (dpkg/apt provider at least) https://projects.puppetlabs.com/issues/5319 Author: Nick Moffitt Status: Needs design decision Priority: Normal Assignee: Nigel Kersten Category: package Target version: Affected Puppet version: Keywords: Branch: At times there are packages with catastrophic failure modes when they are run noninteractively, particularly when working with dpkg. As a result I propose the following option in package providers, presented from a dpkg standpoint. If a package resource is ensure => selected, it will have exactly the same status behavior as ensure => installed, but the installation process will run 'echo "${packagename} install" | /usr/bin/dpkg --set-selections'. This will cause the package to be installed the next time an administrator interactively runs "apt-get dselect-upgrade". This allows configuration changes for a particular package to be held back until that package is installed interactively. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
