Control: retitle -1 apt: set default archs for sources.list lines Control: severity -1 wishlist
On 8 September 2012 03:22, Yann Dirson <[email protected]> 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
