I do agree however that type-handling does not do the right thing here
and will not do the right thing with mutliarch. I'm not really sure
what the right type-handling output for an amd64/i386 system would be
but I guess it should be something like

Provides: i386 amd64 not+i386 not+amd64 ...

The not+<cpu> syntax does not really make much sense when multiple
architectures are supported. The current type-handling does not
provides the "right" things in either the amd64 not the i386 deb for
such a system.

And consider kfreebsd-amd64 architecture. It can directly
run kfreebsd-amd64, kfreebsd-i386 and (linux-)i386 binaries
and of course some other via qemu ;-)

The only correct solution for multiarch is to get rid of type-handling
or at least get rid of type-handling "Provides:".

It should not be so hard. The current dpkg supports wildcards
like [linux-any] and [any-i386], therefore it should not be a
problem for arch specific packages.

It remains to provide solution only for arch all for things like
Depends: libselinux-dev [linux-any]

And of course teach various build-tools about architecture wildcards
in Build-Depends lines.

Petr






--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to