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 <samtres...@gmail.com> 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 puppet-users+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
