Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Mon, Apr 30, 2012 at 04:02:57PM +0200, Goswin von Brederlow wrote:
> Yann Dirson <ydirson@free.fr> writes:
>
> > On Fri, Apr 27, 2012 at 09:53:26PM +0200, Yann Dirson wrote:
> >> On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote:
> >> > Yann Dirson <ydirson@free.fr> writes:
> >> >
> >> > > Package: apt
> >> > > Version: 0.8.15.10
> >> > > Severity: normal
> >> > >
> >> > > (found no changelog entry for 0.9.x looking like this problem)
> >> > >
> >> > > I have many sources.list entries, and only want selected ones to take
> >> > > armel packages into account. The new [arch=] tag seems tailored for
> >> > > this, but then, APT::Architectures defaults to all foreign archs
> >> >
> >> > This works the other way around. arch=... is to limit the architectures.
> >> > The default is ment to be all APT::Architectures.
> >>
> >> Just to be sure: even if there is some way to setup sources the way I
> >> wanted to do it, there still appears to be a bug that prevents apt to
> >> even manipulate (even remove) a foreign package when its arch has been
> >> removed from APT::Architectures:
> >>
> >> # apt-get remove libc6:armel
> >> Reading package lists... Done
> >> Building dependency tree
> >> Reading state information... Done
> >> E: Unable to locate package libc6:armel
> >
> > If I re-enable armel and proceed with removal (a newer libc6:amd64 had
> > already been installed causing breakage, see Bug#670668), I get a
> > cryptic error from dpkg, but can't be sure who's causing it - at least
> > things seem back in working order as far as packages seem concerned:
> >
> > (Reading database ... 438877 files and directories currently installed.)
> > Removing libgcc1:armel ...
> > dpkg: libc6:armel: dependency problems, but removing anyway as you requested:
> > locales depends on glibc-2.13-1; however:
> > Package glibc-2.13-1 is not installed.
> > Package libc6:armel which provides glibc-2.13-1 is to be removed.
> > Package libc6:amd64 which provides glibc-2.13-1 is not configured yet.
>
> This is a bit ugly. I guess dpkg is technically right. locales depends
> on glibc-2.13-1 and libc6:amd64 (the last thig providing it) is not
> configured yet. So your action does break the dependency of
> locales. Locales would have to be deconfigured or libc6:amd64 would have
> to be configured.
>
> > Removing libc6:armel ...
> > dpkg: error: --configure needs a valid package name but 'libc6' is not: ambiguous package name 'libc6' with more than one installed instance
>
> But then it goes and tries to configure libc6. Where did that come from
> and why is it still ambiguous? Do you have libc6:i386 installed too? But
> then the above error would have been wrong.
Not at all, the only foreigth arch here is armel.
> What was your command line that caused this?
Hm, should have been the "apt-get remove libc6:armel" show above
> > Type dpkg --help for help about installing and deinstalling packages [*];
> > Use `dselect' or `aptitude' for user-friendly package management;
> > Type dpkg -Dhelp for a list of dpkg debug flag values;
> > Type dpkg --force-help for a list of forcing options;
> > Type dpkg-deb --help for help about manipulating *.deb files;
> >
> > Options marked [*] produce a lot of output - pipe it through `less' or `more' !
> > E: Sub-process /usr/bin/dpkg returned an error code (2)
> > A package failed to install. Trying to recover:
> > Setting up libc6:amd64 (2.13-30) ...
> > Setting up libc6-dbg:amd64 (2.13-30) ...
> > Setting up libc-dev-bin (2.13-30) ...
> > Setting up libc6-i386 (2.13-30) ...
> > Setting up libc6-dev (2.13-30) ...
> > Setting up libc6-dev-i386 (2.13-30) ...
> > Press return to continue.
>
> That looks like aptitude. Can I assume aptitude called:
>
> dpkg --remove libc6:armel
> dpkg --configure libc6
> dpkg --configure -a
>
> If this was from an aptitude run then that should be filed as a seperate
> bug against aptitude.
>
> MfG
> Goswin
Reply to: