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 <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'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
Reply to: