Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Mon, Sep 10, 2012 at 4:17 AM, Daniel Hartwig mand...@gmail.com wrote: On 8 September 2012 03:22, Yann Dirson ydir...@free.fr wrote: Well, the only thing left I can think of, is that on a setup where I have a large number of apt sources, but only want a small subset of them to pick armel packages from, I cannot just tag them as such, but have to tag the large number as not taking them, precisely by *not* mentionning them in the [arch=] list. This is pretty much verbose and IMHO unintuitive. Maybe we could be have a DefaultSourceListArchs setting of some sort, which would default to the APT::Architectures list, but could be overriden to a subset thereof to eventually exclude the foreign arch by default, and be overriden per-line to re-enable it ? Personally I do not find the [arch=] syntax unintuitive. I suppose your initial impressions were from trying something unsupported by multiarch :-) Such a setting can be useful for some edge cases, though configuring sources is such a rare exercise there may not be much to gain. APT::Sources::Default-Architectures ? I wonder if this isn't better served by providing a syntax to add and remove architectures from the list, much like tags for bugreports: arch=armel # only get armel arch=-armel # get everything from APT::Architectures expect armel arch=+armel # get everything from APT::Architectures and armel (Sidenote: apt/preferences does not seem to allow scoring based on arch, so I cannot pin armel packages to squeeze on this box where the native packages are usually pinned to testing - maybe worth its own bugreport) Package: *:armel Pin: release n=squeeze Pin-Priority: 991 Arch-qualification will work for specific-packages stanzas only, but you can do this: Package: * Pin: release n=squeeze,b=armel Pin-Priority: 991 Ah cool, but my original note was based on misunderstanding of the feature: I cannot have different versions of a single package for different archs (which is in fact why the setup was not really adapted to my needs - I needed a chroot anyway) Ok. Indeed this is not supported by multi-arch (in fact, it specifically disallows it). Yeap, this is by design. It would get really really messy if this would be allowed (think of files in /etc for example - does this file has the syntax of version 1 or of version 2 …) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On 11 September 2012 00:17, David Kalnischkies kalnischkies+deb...@gmail.com wrote: APT::Sources::Default-Architectures ? I wonder if this isn't better served by providing a syntax to add and remove architectures from the list, much like tags for bugreports: arch=armel # only get armel arch=-armel # get everything from APT::Architectures expect armel This looks good also. The negative filter is precisely what the original report was anticipating. arch=+armel # get everything from APT::Architectures and armel One caveat with this type of entry (and APT::Sources::Default-Architectures, if it contains extra archs also) is #451369, where APT has trouble with installed packages from these “extra” architectures if they do not also appear in a current source. This will probably have to be resolved to enable such a format. (Sidenote: apt/preferences does not seem to allow scoring based on arch, so I cannot pin armel packages to squeeze on this box where the native packages are usually pinned to testing - maybe worth its own bugreport) Package: *:armel Pin: release n=squeeze Pin-Priority: 991 Arch-qualification will work for specific-packages stanzas only, A bit of a hack but it worked when I tested it. apt-cache policy listed every armel package as pinned, which is not very nice output ;-) but you can do this: Package: * Pin: release n=squeeze,b=armel Pin-Priority: 991 A better format, though it is not documented or working (?) in 0.9.7.4: $ cat /etc/apt/preferences Package: * Pin: release a=experimental,b=amd64 Pin-Priority: 992 $ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 1 http://ftp.iinet.net.au/debian/debian/ experimental/main i386 Packages release o=Debian,a=experimental,n=experimental,l=Debian,c=main origin ftp.iinet.net.au 1 http://ftp.iinet.net.au/debian/debian/ experimental/main amd64 Packages release o=Debian,a=experimental,n=experimental,l=Debian,c=main origin ftp.iinet.net.au 500 http://ftp.iinet.net.au/debian/debian/ sid/main i386 Packages release o=Debian,a=unstable,n=sid,l=Debian,c=main origin ftp.iinet.net.au 500 http://ftp.iinet.net.au/debian/debian/ sid/main amd64 Packages release o=Debian,a=unstable,n=sid,l=Debian,c=main origin ftp.iinet.net.au Pinned packages: Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
Control: retitle -1 apt: set default archs for sources.list lines Control: severity -1 wishlist On 8 September 2012 03:22, Yann Dirson ydir...@free.fr wrote: Well, the only thing left I can think of, is that on a setup where I have a large number of apt sources, but only want a small subset of them to pick armel packages from, I cannot just tag them as such, but have to tag the large number as not taking them, precisely by *not* mentionning them in the [arch=] list. This is pretty much verbose and IMHO unintuitive. Maybe we could be have a DefaultSourceListArchs setting of some sort, which would default to the APT::Architectures list, but could be overriden to a subset thereof to eventually exclude the foreign arch by default, and be overriden per-line to re-enable it ? Personally I do not find the [arch=] syntax unintuitive. I suppose your initial impressions were from trying something unsupported by multiarch :-) Such a setting can be useful for some edge cases, though configuring sources is such a rare exercise there may not be much to gain. APT::Sources::Default-Architectures ? I'll leave this here as a wishlist. (Sidenote: apt/preferences does not seem to allow scoring based on arch, so I cannot pin armel packages to squeeze on this box where the native packages are usually pinned to testing - maybe worth its own bugreport) Package: *:armel Pin: release n=squeeze Pin-Priority: 991 Ah cool, but my original note was based on misunderstanding of the feature: I cannot have different versions of a single package for different archs (which is in fact why the setup was not really adapted to my needs - I needed a chroot anyway) Ok. Indeed this is not supported by multi-arch (in fact, it specifically disallows it). I am glad to learn that you eventually were able to do what you needed with the classic chroot :-) Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Fri, Sep 07, 2012 at 12:41:36PM +0800, Daniel Hartwig wrote: Yann Dirson ydir...@free.fr wrote: 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 Hello Just following up on your experiences mentioned in this report and the related ones. It seems as though you were incorrectly using APT::Architectures and [arch=]. To be precise, the recommended configuration for the situation in your original report is: $ dpkg --print-architecture amd64 $ dpkg --print-foreign-architectures armel $ apt-config dump | grep -i ^APT::Architecture APT::Architecture amd64; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: armel; $ cat /etc/apt/sources.list deb [arch=amd64] ftp://ftp.debian.org/debian testing main deb ftp://ftp.debian.org/debian squeeze main Which I think you eventually implemented. It is important that APT::Architectures contains an entry for every architecture of an installed package. I understand that, while trying to sort this out, you removed armel from APT::Architectures and proceeded with an upgrade which caused some problems with libc6 on this system. That issue is tracked as #670668: apt is unaware of installed packages whose architecture is not in APT::Architectures. Did you ever recover your system from the libc6 issue? (Please do not close #670668 as the issue still applies to apt generally.) Yes, I eventually purged all remaining armel packages, as they prevented upgrades of the amd64 ones. Also, are you now using the correct configuration mentioned above (or something similar) No, since in fact the setup was not really adapted to my needs. and does this work as you expected? If so, I believe we can close this bug (#670322). Well, the only thing left I can think of, is that on a setup where I have a large number of apt sources, but only want a small subset of them to pick armel packages from, I cannot just tag them as such, but have to tag the large number as not taking them, precisely by *not* mentionning them in the [arch=] list. This is pretty much verbose and IMHO unintuitive. Maybe we could be have a DefaultSourceListArchs setting of some sort, which would default to the APT::Architectures list, but could be overriden to a subset thereof to eventually exclude the foreign arch by default, and be overriden per-line to re-enable it ? (Sidenote: apt/preferences does not seem to allow scoring based on arch, so I cannot pin armel packages to squeeze on this box where the native packages are usually pinned to testing - maybe worth its own bugreport) Package: *:armel Pin: release n=squeeze Pin-Priority: 991 Ah cool, but my original note was based on misunderstanding of the feature: I cannot have different versions of a single package for different archs (which is in fact why the setup was not really adapted to my needs - I needed a chroot anyway) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
Yann Dirson ydir...@free.fr wrote: 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 Hello Just following up on your experiences mentioned in this report and the related ones. It seems as though you were incorrectly using APT::Architectures and [arch=]. To be precise, the recommended configuration for the situation in your original report is: $ dpkg --print-architecture amd64 $ dpkg --print-foreign-architectures armel $ apt-config dump | grep -i ^APT::Architecture APT::Architecture amd64; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: armel; $ cat /etc/apt/sources.list deb [arch=amd64] ftp://ftp.debian.org/debian testing main deb ftp://ftp.debian.org/debian squeeze main Which I think you eventually implemented. It is important that APT::Architectures contains an entry for every architecture of an installed package. I understand that, while trying to sort this out, you removed armel from APT::Architectures and proceeded with an upgrade which caused some problems with libc6 on this system. That issue is tracked as #670668: apt is unaware of installed packages whose architecture is not in APT::Architectures. Did you ever recover your system from the libc6 issue? (Please do not close #670668 as the issue still applies to apt generally.) Also, are you now using the correct configuration mentioned above (or something similar) and does this work as you expected? If so, I believe we can close this bug (#670322). (Sidenote: apt/preferences does not seem to allow scoring based on arch, so I cannot pin armel packages to squeeze on this box where the native packages are usually pinned to testing - maybe worth its own bugreport) Package: *:armel Pin: release n=squeeze Pin-Priority: 991 Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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 ydir...@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 ydir...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
Yann Dirson ydir...@free.fr writes:
On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote:
Yann Dirson ydir...@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.
Ah OK. But then, apt should probably not fetch the package list for
armel even when it is specified using arch=, isn't it ?
-- /etc/apt/sources.list --
deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free
fetch only binary-amd64/Packages
deb ftp://ftp.debian.org/debian squeeze main
fetch all binary-{Apt::Architectures}/Packages
deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free
...
deb ftp://ftp.debian.org/debian squeeze main
MfG
Goswin
At least that was the idea and implementation when I wrote the patch and
when it was initially added.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
Yann Dirson ydir...@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 ydir...@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. What was your command line that caused this? 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote: Yann Dirson ydir...@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. Ah OK. But then, apt should probably not fetch the package list for armel even when it is specified using arch=, isn't it ? -- /etc/apt/sources.list -- deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free ... deb ftp://ftp.debian.org/debian squeeze main deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free ... deb ftp://ftp.debian.org/debian squeeze main MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
On Wed, Apr 25, 2012 at 11:12:42AM +0200, Goswin von Brederlow wrote: Yann Dirson ydir...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
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 ydir...@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. 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 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
Yann Dirson ydir...@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. -- /etc/apt/sources.list -- deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free ... deb ftp://ftp.debian.org/debian squeeze main deb [ arch=amd64 ] ftp://ftp.debian.org/debian testing main contrib non-free ... deb ftp://ftp.debian.org/debian squeeze main MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works
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
(Sidenote: this situation is probably OK when foreign archs are
directly executable (eg. i386 on amd64), but for cross-compiling
purposes it it less OK)
... and apt ignores my tag and just downloads any armel Packages file
it can find - at least, I am able to install foreign packages, it just
does not installs by default the versions I want, and complains for
sources which do not provide an armel version.
(Sidenote: apt/preferences does not seem to allow scoring based on
arch, so I cannot pin armel packages to squeeze on this box where the
native packages are usually pinned to testing - maybe worth its own bugreport)
Now if I tell apt to only consider amd64 by default, with:
APT::Architectures { amd64; };
... then apt-get update *does* fetch only the correct files, with a
single armel Packages file, but then, neither of apt-get/apt-cache/aptitude
want to talk about armel packages again, even for installed ones:
# dpkg -l libc6:armel
...
ii libc6:armel 2.13-27
# apt-cache policy libc6:armel
N: Unable to locate package libc6:armel
And if I comment out this APT::Architectures line and run apt-get update again:
# apt-cache policy libc6:armel
libc6:armel:
Installed: 2.13-27
Candidate: 2.13-27
...
Maybe I'm just trying to use the wrong feature to do what I need - I
had to guess since the sources.list manpage does not really tell that
the [arch=] syntax is not expected to be useful out of the box, nor in
which situations it is expected to be useful.
-- Package-specific info:
-- apt-config dump --
APT::Architecture amd64;
...
APT::Architectures ;
APT::Architectures:: amd64;
-- (/etc/apt/preferences present, but not submitted) --
-- /etc/apt/sources.list --
deb ftp://ftp.debian.org/debian testing main contrib non-free
...
deb [ arch=amd64,armel ] ftp://ftp.debian.org/debian squeeze main
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages apt depends on:
ii debian-archive-keyring 2010.08.28
ii gnupg 1.4.12-4
ii libc6 2.13-27
ii libgcc1 1:4.7.0-3
ii libstdc++6 4.7.0-3
ii zlib1g 1:1.2.6.dfsg-2
apt recommends no packages.
Versions of packages apt suggests:
ii apt-doc none
ii aptitude0.6.6-1
ii bzip2 1.0.6-1
ii dpkg-dev1.16.2
ii python-apt 0.8.3+nmu1
ii xz-lzma [lzma] 5.1.1alpha+20110809-3
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
