Re: Architecture: all + M-A: foreign
[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. (:
Reply to: