I guess I'm confused at why aptitude would remove php5-memcache in order to upgrade php5-common. Or if it really needed to do that, shouldn't it be smart enough to automatically install the upgraded version? I confess I'm more familiar with RedHat/CentOS, and Yum is smart enough to handle upgrading packages and their dependencies smoothly. I had though aptitude was smart enough too, based on my limited experience with it. Anyway, if you're still stuck I guess that's what I would try to figure out.
On Thu, Sep 19, 2013 at 9:23 AM, Sam Tresler <[email protected]> wrote: > Actually, that isn't going to work, I don't think. I need to have some > method of flagging the uninstalled packages as needing reinstallation mid > puppet run, or I need aptitude to not uninstall them in the first place, or > I need to I need puppet to get kicked off on a second run at the end of the > first. Of those I like the first or second options best. I'll do more > digging, but would love to hear people's suggestions on this as well. > > > On Thursday, September 19, 2013 9:58:21 AM UTC-4, Sam Tresler wrote: >> >> Ah. That makes a lot of sense. I'd noticed the php5-mysql 'upgrade' and >> assumed I was getting an erroneous message, but if puppet thinks it is >> doing that there is actually no difference in the aptitude commands between >> an install and an upgrade. The packages with names that match php5-common >> *do* register as needing an upgrade at the beginning of the run, and are >> actually caught and reinstalled mistakenly. Anything that doesn't need an >> upgrade is never touched because it didn't need anything in the first >> place. >> >> My predecessor switched to running puppet non-daemonized on a 20m cron >> job. And I think this would not be an issue in a daemonized mode (perhaps) >> - as puppet would see the inconsistency faster, which is why I can find >> NOTHING on google about a similar problem. >> >> So, I think I'll proceed by having the php extensions without the same >> versioning schema subscribe to the php5-common resource and (I'll have to >> see what options are there) and check themselves again or kick off a second >> puppet run immediately. >> >> Thanks a ton. I had all the pieces but couldn't quite see it. >> >> On Thursday, September 19, 2013 9:39:01 AM UTC-4, jcbollinger wrote: >>> >>> >>> >>> On Wednesday, September 18, 2013 3:01:49 PM UTC-5, Sam Tresler wrote: >>>> >>>> Hi, I've inherited a puppet setup for automating php installation and >>>> extension management. We're on Debian and we've encountered a strange >>>> issue that I've traced down back to puppet I think. I've stripped back the >>>> configuration and made the problem reproducible, logs and config pasted >>>> below. >>>> >>>> 1. php5-common, php5-memcache, and php5-mysql are all installed. >>>> 2. php5-common and php5-mysql receive an update, say from >>>> 5.3.3-7+squeeze14 to 5.3.3-7+squeeze17 >>>> 3. Puppet runs and php5-common upgrade conflicts. Apt's first solution >>>> removes php5-mysql and php5-memcache. >>>> 4. Puppet continues run and re-installs/upgrades php5-mysql. It skips >>>> php5-memcache. >>>> 5. On a subsequent run php5-memcache is installed again as expected. >>>> >>>> This appears to only happen to packages that don't share the php5 >>>> version naming schema, but that may be just a clue, not a cause. e.g. >>>> php5-memcache is 3.0.4-4+squeeze1. >>>> >>> >>> >>> Yes, that's a clue, not the cause. Here's what I think is happening: >>> >>> Early in the run, before applying any resources, the Puppet agent >>> "prefetches" the installed apt packages. This is a common behavior of >>> providers for many resource types where it is more efficient than loading >>> each declared resource's initial state individually. Puppet thereafter >>> assumes that the data it has prefetched do not change except as the agent >>> itself explicitly changes them. In particular, it will be caught quite by >>> surprise if one of the resources it has prefetched is no longer present on >>> the system when it comes time to apply it. >>> >>> If you look carefully at the log, you will see that it is not just >>> php5-memcache about which the agent is confused. The log also says: >>> 'php5-mysql "5.3.3-7+squeeze14" is installed', which is no longer true at >>> the time that that message is emitted. It happens that the result is >>> nevertheless what you want in that case, however, because the reason the >>> package was removed is correlated with the availability of a later version >>> of it. >>> >>> This explanation assumes that the latest available version of >>> php5-memcache is the same one that was already installed at the start of >>> the Puppet run. In that case, however, it is a mystery beyond my >>> understanding why that package needed to be removed for the update to >>> php5-common to proceed, and it was not automatically reinstalled, yet it >>> could later be reinstalled manually. >>> >>> >>> John >>> >>> -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-users. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
