Bug#43077: [Proposal]: Remove the incompatibility argument from 5.1
Package: debian-policy
Severity: wishlist
> 5.1. Architecture specification strings
> ---------------------------------------
> If a program needs to specify an _architecture specification string_
> in some place, the following format has to be used:
>
> <arch>-<os>
>
> where `<arch>' is one of the following: i386, alpha, arm, m68k,
> powerpc, sparc and `<os>' is one of: linux, gnu. Use of _gnu_ in this
> string is reserved for the GNU/Hurd operating system. .
>
> Note, that we don't want to use `<arch>-debian-linux' to apply to the
> rule `architecture-vendor-os' since this would make our programs
> incompatible to other Linux distributions. Also note, that we don't
> use `<arch>-unknown-linux', since the `unknown' does not look very
> good.
I cannot follow the rationale for the compatibility argument. Most
Debian packages are built without an explicit architecture
string. For most of these packages this doesn't matter, because the
gnu build architecture is only used in error and help messages
(i.e. gdb). Does such a package violate policy?
Giving <arch>-<os> as the gnu build architecture makes these packages
incompatible with other distributions. I don't say, policy contradicts
itself, but this argument only makes sense, if the this architecture
string is selected for all linux distributions. Do I may miss here
some other arguments?
Other linux distributions do make use of the vendor place of their own
(redhat, suse) or use `pc' for this field. Given that the Debian way
(<arch>-<os>) already is incompatible, why not use <arch>-debian-<os>,
so you see the branding of the binaries? The counter argument for this
is the intended use of the field for the _hardware_ vendor.
Using the vendor field makes sense for identifying test results and
bug reports, where the build info is extracted and sent with the
report to an upstream source mailing list.
Reply to: