[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: