Re: Strange architechture problem
On Monday 23 May 2016 11:28:38 The Wanderer wrote:
> On 2016-05-22 at 23:53, Gene Heskett wrote:
> > Greetings all;
> >
> > I apparently play with the amd64 architecture in my dpkg
> > architecture list long enough to screw it up, but not fatally so
> > far.
> >
> > I have a libexpat1:amd64 files installed, but so far I have been
> > unsuccessful at getting it replaced with the next version of that
> > file in i386 format, which matches the install.
>
> Why would you need to _replace_ one with the other? It should be
> entirely possible to have both installed side-by-side; I do.
>
> > My last attempt generated this failure, so I need a dpkg guru again.
> > ==========================
> > gene@coyote:/var/cache/apt/archives$ sudo
> > dpkg -i --force-remove-reinstreq libexpat1_2.1.0-1+deb7u3_i386.deb
> > libexpat1-dev_2.1.0-1+deb7u3_i386.deb
> > (Reading database ... 421567 files and directories currently
> > installed.) Preparing to replace libexpat1:i386 2.1.0-1+deb7u3
> > (using
> > libexpat1_2.1.0-1+deb7u3_i386.deb) ...
> > Unpacking replacement libexpat1:i386 ...
> > Preparing to replace libexpat1-dev 2.1.0-1+deb7u3 (using
> > libexpat1-dev_2.1.0-1+deb7u3_i386.deb) ...
> > Unpacking replacement libexpat1-dev ...
> > dpkg: error processing libexpat1:i386 (--install):
> > package libexpat1:i386 2.1.0-1+deb7u3 cannot be configured because
> > libexpat1:amd64 is at a different version (2.1.0-1+deb7u2)
> > dpkg: dependency problems prevent configuration of libexpat1-dev:
> > libexpat1-dev depends on libexpat1 (= 2.1.0-1+deb7u3); however:
> > Package libexpat1:i386 is not configured yet.
> >
> > dpkg: error processing libexpat1-dev (--install):
> > dependency problems - leaving unconfigured
> > Errors were encountered while processing:
> > libexpat1:i386
> > libexpat1-dev
> > gene@coyote:/var/cache/apt/archives$
> > =================================
> > I haven't tried removing the -dev package by itself yet, but that
> > just failed too.
>
> Failed how?
>
> At a guess, I'd imagine it might have failed because libexpat1:i386 is
> in a bad state. If so, removing libexpat1:i386 first should let
> removing the -dev package work as expected.
>
> > How can I force dpkg to replace the erroneously installed amd64
> > version without its destroying the rest of the system because of the
> > many dependencies would cause it to nuke at least another 50
> > packages?
>
> Does 'apt-get install libexpat1:i386 libexpat1:amd64-' not do the job?
>
> If not, I see two options offhand:
>
> * Obtain a .deb file for libexpat1:i386 which has a version matching
> the version of libexpat1:amd64 which you already have installed, and
> try installing that.
>
> * Install a version of libexpat1:amd64 which matches the version of
> the libexpat1:i386 .deb you have, install that, then try your existing
> dpkg command again.
>
> In either case, if it works, you may be able to remove the :amd64
> version later on with a separate command. (Installing an :i386 version
> of a library does not replace the :amd64 version of the same library,
> unless the library is not multiarch-ified, which this one is; it just
> installs the second library in parallel to the first one.)
>
> > Where is the dpkg unconditional "--force-replace" option IOW?
>
> I don't think there is one, not on as universal a scale as you're
> apparently asking for. Multi-arch libraries have to be kept at exactly
> the same version, or you're just asking for trouble; it wouldn't
> surprise me at all if dpkg simply does not support attempting to
> install versions which don't match.
please, try telling that to the package manager, which has had the amd64
arch removed from its choices list, and would like to install the i386
version 7u3, inplace of the 7u2 version that is labeled amd64. Synaptic
installed it without a fuss some months back, but I realized that I
couldn't just replace the libc6 install on a live system, and removed
the amd64 arch from its arch list, and am now trying to clean it up
again after upgrading the kernel to a 64 bit one that was still capable
of running the linuxcnc simulation. That was because the formerly pinned
kernel, patched for real time use, claimed it was a 32 bit PAE kernel
but was not in fact a PAE, so I was 1 gigbyte or more into swap in 2
days uptime. This kernel, a 64 bitter, sees all 8 gigs of my ram and
may have 100 megs in swap after a months uptime. Thats one heck of a
difference.
But now, even if what synaptic installs needs a reboot to be effective,
it does not recommend or force the reboot because the update of these
two packages back to the i386 versions did not complete. Such an update
should not in my opinion, be blocked if the package being overwritten is
both older, and the wrong architecture for the rest of the system.
I did in in fact fix another such miss-match about 6 weeks ago, using
dpkg syntax someone suggested, but cannot find that message again.
The fact that I've done it before says I ought to be able to do it again.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: