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 <ydirson@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)
Reply to: