Package: ucf
Version: 3.0027+nmu1
Severity: normal
Hi folks,
on my system, I have php5-cgi and php5-cli installed, which each have
their respective ucf-registered conffile:
/etc/php5/cgi/php.ini
/etc/php5/cli/php.ini
However, the latter is a symlink to the former:
$ ls -l /etc/php5/cli/php.ini
lrwxrwxrwx 1 root root 14 Mar 14 2011 /etc/php5/cli/php.ini ->
../cgi/php.ini
I suspect that I manually did this at some point, so I wouldn't have to
maintain two config files, which I wanted to be identical at some point.
Now, when upgrading the php5-cli package, ucfr bails out. I've extracted
the relevant command below, but I get the same error during an aptitude
/ dpkg run, causing aptitude to bail out.
$ sudo ucfr php5-cli /etc/php5/cli/php.ini
ucfr: Attempt from package php5-cli to take /etc/php5/cli/php.ini away
from package php5-cgi
ucfr: Aborting.
Looking at the code, ucfr sees that /etc/php5/cli/php.ini is a symlink
to /etc/php5/cgi/php.ini, so it will register the config file under the
latter name. Since it is already registered by a different package, it
errors out.
This is not a very clear-cut bug in ucfr, since I manually messed up my
config files to cause this. However, the symlink I added seems to make
sense and it would be preferable if a change like this would not cause
upgrades to fail. Having said that, I'm not quite sure how ucfr could be
changed to support this usecase, I don't have enough know-how about how
ucf is supposed to work for that. Any suggestions?
Gr.
Matthijs
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.9.0 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ucf depends on:
ii coreutils 8.21-1
ii debconf 1.5.50
ucf recommends no packages.
ucf suggests no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]