[Helmut Grohne] > I ask you not to use this proposal for the following reasons: > > * Given a package it is now much harder to see whether it is tagged M-A > or not. Especially you can no longer determine the tagging by simple > examination of package lists.
That's fair. Though I imagine if apt knew about this mapping, it could just add 'M-A: foreign' to its package cache, so you would see it with 'apt-cache show' or 'apt-cache dumpavail'. Anyway, it's a concern. > * Changing one package from Arch:all to Arch:any suddenly can break > another package. An effect that one might not expect. Well, today, changing one package from Arch:any to Arch:all can suddenly break another package. (Same problem: lack of M-A:foreign.) Perhaps you think that is unexpected as well, but it is reality. > * If for some reason the package is actually not M-A:foreign there is > no way to overrule the implicit decision besides turning the package > to Arch:any or introducing a new artificial Arch:any dependency. The only reason that I have seen that Arch:all is not _always_ treated as M-A:foreign, relates to recursive dependency resolution: foo:i386 -> foo-data:all -> bar:amd64, where foo:i386 and bar:amd64 cannot properly interact. My proposed rule accounts for that case. Can you think of any _other_ reasons not to set M-A:foreign on an Arch:all package? > As a counter proposal I would like to ask whether such an implicit > header could be added by debhelper (at a high enough compatibility > level) by default. Could be done - dh could do the same analysis I'm asking apt to do. I believe traditionally dh does not mess with debian/control beyond what dpkg-gencontrol does with substvars and such, but I suppose that doesn't mean it _couldn't_. > Maybe the problem also solves itself after extending dh-make? ;-) Heh - dh-make doesn't have enough context to know whether M-A:foreign makes sense. (: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121206092000.gm4...@p12n.org
