More expressive Multi-Arch field
- Date: Wed, 18 Apr 2018 08:00:53 +0000
- From: Lumin <cdluminate@xxxxxxxxx>
- Subject: More expressive Multi-Arch field
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, and I think there could be three cases
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,
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.
policy and dev-ref don't explain the Multi-Arch field.--