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
Attachment:
signature.asc
Description: Digital signature