Bug#670322: apt: hiding foreign arch from APT::Architectures, using with [arch=] only, only partly works

[David Kalnischkies <kalnischkies+debian@gmail.com>]

On Mon, Sep 10, 2012 at 4:17 AM, Daniel Hartwig <mandyke@gmail.com> wrote:
> On 8 September 2012 03:22, Yann Dirson <ydirson@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