More expressive Multi-Arch field
Hello folks,
I found myself prone to forget what "same" or "foreign" means
in the Multi-Arch section. Once and once again I have to lookup
docs to fugure out what they stand for. These two words don't
explicitly present their meaning. Based on this, I'm writting to
put forward an idea for improving this field.
I have read Osamu's doc[1], and I think there could be three cases
of Multi-Arch:
1. Multi-Arch: co-installable
e.g. we have libfoo1 which puts a .so file under /usr/lib/triplet.
In this case libfoo1:amd64 is co-installable with, for instance,
libfoo1:i386 .
2. Multi-Arch: exclusive
e.g. we have a package libfoo-tools which puts ELFs to /usr/bin.
In this case this binary is not co-installable with libfoo-tools
compiled for another arch. Hence it is "exclusive".
3. Multi-Arch: universal / indep
e.g. we have a pure python package python-bar. This package
is usable on all the archs, or say independent to archs.
These packages can be marked as "indep" or e.g. "universal".
Compared to "same"/"foreign", the idea above provides a more
expressive and self-doc'd Multi-Arch field.
Your opinion?
policy and dev-ref don't explain the Multi-Arch field.
--
Best,
Reply to: