Precisely. Aptitude is the culprit here. I've switched our package manager
to apt which is more conservative and it does not remove the packages when
upgrading php, which, for now is a workable solution. I need to find the
time to put this in as Debian bug and see what they say.
I can't see
Precisely. Aptitude is the culprit here. I've switched our package manager
to apt which is more conservative and it does not remove the packages when
upgrading php, which, for now is a workable solution. I need to find the
time to put this in as Debian bug and see what they say.
I can't see
On Wednesday, September 25, 2013 8:17:42 AM UTC-5, Sam Tresler wrote:
Precisely. Aptitude is the culprit here. I've switched our package manager
to apt which is more conservative and it does not remove the packages when
upgrading php, which, for now is a workable solution. I need to find
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
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
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
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
