Nigel Ridley wrote: > Grahame White wrote: > > Unpacking replacement libc6 ... > > dpkg: error processing /var/cache/apt/archives/libc6_2.3.5-3_amd64.deb > > (--unpack): > > trying to overwrite `/usr/lib64', which is also in package xmms-kde
This seems like a very strange thing to see here. I think the xmms-kde package has a problem. I looked at the package source but it is built with cdbs and I have not worked with it previously and don't grok it. Can someone else crosscheck that package? The parts that I think are a problem are these: drwxr-xr-x root/root 0 2004-12-10 14:49:00 ./usr/lib64/ drwxr-xr-x root/root 0 2004-12-10 14:49:02 ./usr/lib64/kde3/ -rw-r--r-- root/root 605744 2004-12-10 14:49:02 ./usr/lib64/kde3/libxmmskde.so -rw-r--r-- root/root 1641 2004-12-10 14:48:58 ./usr/lib64/kde3/libxmmskde.la Crosschecking this to the official ia64 package I do not see /usr/lib64 there but rather /usr/lib there as I would expect on a pure64 package. Here is the ia64 version of the package. drwxr-xr-x root/root 0 2004-12-07 01:46:10 ./usr/lib/ drwxr-xr-x root/root 0 2004-12-07 01:46:12 ./usr/lib/kde3/ -rw-r--r-- root/root 1050544 2004-12-07 01:46:12 ./usr/lib/kde3/libxmmskde.so -rw-r--r-- root/root 1418 2004-12-07 01:46:09 ./usr/lib/kde3/libxmmskde.la Just the same when I test installed it on my machine I did not see the error that you reported. I was unable to recreate the problem. > In /etc/apt/apt.conf.d/ there is a file: 70debconf If you are making personal customizations it would be better to make them in a separate file. The 70debconf file is part of the debconf package. Of course you can make changes and it will ask you on upgrade if you want to keep your modified file or install the new one. But then you need to check and merge your changes with the new one every time it upgrades. Better to put your changes in a separate file and avoid that issue. That is why there is an entire directory of possible files that will all be loaded there. Generally the directory of files /etc/apt/apt.conf.d/* is for packages and other automated script processes. They can add the file or remove the file as they choose. Sure you can add other files or modify the existing files too. Generally local admin would edit the /etc/apt/apt.conf file which is never modified by any package or other automated process. I suggest putting your manual changes there and leaving the .d directory untouched unless you are also building automated processes to install configuration there automatically. > Add this to the file: > > DPkg > { > // Probably don't want to use force-downgrade.. > Options {"--force-overwrite";} > } > > Then, whenever the situation arises, dpkg will automatically overwrite > the common file. I think that is a very bad idea. In the future if you were to have an important file conflict this will hide the conflict entirely. It is such a rare event that you would need to install and force a conflict I think it is better to approve the conflict manually at those very rare times when it is appropriate than to disable the check permanently. > It's worked for me several times :-) This is one of those things that works fine when the system is working. Because if there are no conflicting files in packages and the depot is in a happy state you will not see any problems. It is not until while tracking Sid that some unpleasant file conflict will appear in the depot that without this option you would notice and avoid the upgrade and avoid the breakage. But with this option set you will not notice the problem and can get your system into an interesting broken state. I really recommend against this configuration. Bob
signature.asc
Description: Digital signature