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
