Debian Bug report logs - #664257
document Architecture name definitions

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Matthias Klose <doko@debian.org>

Date: Sat, 17 Mar 2012 06:18:01 UTC

Severity: normal

Tags: upstream

Found in version debian-policy/3.9.3.1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Sat, 17 Mar 2012 06:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Sat, 17 Mar 2012 06:18:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: multiarch tuples are not documented/defined
Date: Sat, 17 Mar 2012 07:03:09 +0100
Package: general
Severity: serious
Tags: wheezy, sid

While we strive to get multiarch ready for squeeze, there is currently nothing 
to point to what the multiarch tuples actually mean, neither on the Debian side 
nor on some kind of standards side like the FHS or LSB.  This has to be 
documented on the Debian side, and better be incorporated into standards like 
the FHS or LSB.

The current state is http://wiki.debian.org/Multiarch/Tuples, deriving from 
http://wiki.debian.org/Multiarch/TuplesAbandoned. An email to debian-ports 
didn't get any feedback. From my point of view such a wiki page should be 
self-contained and be usable as a reference for upstream projects.  My current 
concern is that upstream builds of GCC and binutils are currently broken and 
patch submissions to GCC are on hold until such a definition is available at 
least on the Debian side.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Sat, 17 Mar 2012 13:10:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Sat, 17 Mar 2012 13:10:03 GMT) Full text and rfc822 format available.

Message #10 received at 664257@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Matthias Klose <doko@debian.org>
Cc: 664257@bugs.debian.org
Subject: Re: multiarch tuples are not documented/defined
Date: Sat, 17 Mar 2012 08:06:16 -0500
Matthias Klose wrote:

> While we strive to get multiarch ready for squeeze, there is
> currently nothing to point to what the multiarch tuples actually
> mean, neither on the Debian side nor on some kind of standards side
> like the FHS or LSB.  This has to be documented on the Debian side,
> and better be incorporated into standards like the FHS or LSB.
>
> The current state is http://wiki.debian.org/Multiarch/Tuples,
> deriving from http://wiki.debian.org/Multiarch/TuplesAbandoned. An
> email to debian-ports didn't get any feedback. From my point of view
> such a wiki page should be self-contained and be usable as a
> reference for upstream projects.

Thanks.  To start (warning: the following is just a bunch of guesses,
many of which are almost certainly wrong):

 i386-linux-gnu: Intel ia32 ABI, ELF, Linux syscalls, glibc 2.x.
	psABI is documented in the System V ABI Intel386 architecture
	processor supplement: http://www.sco.com/developers/devspecs/

 x86_64-linux-gnu: Likewise, but using the AMD64 psABI as documented
	in abi.pdf: http://x86-64.org/documentation/

 sparc-linux-gnu: Likewise, but with the SPARC psABI as documented
	in psABI3rd.pdf: http://www.sparc.com/standards/
	Debian uses the v8plus ABI, but I think that is
	backward-compatible with the old svr4 ABI and doesn't have to be
	part of the definition.

 sparc64-linux-gnu: Likewise, but with the SPARC v9 64-bit psABI.
	Not sure where the reference documentation is for that.

 alpha-linux-gnu: Likewise, but with the Tru64 UNIX Calling Standard
	for Alpha Systems:
	http://www.openwatcom.org/ftp/devel/docs/alpha%20calling%20standard.pdf

 m68k-linux-gnu: Likewise, but with the Motorola 68000 Family
	Processor Supplement to the System V ABI which doesn't seem to
	be available oneline. (?)

 arm-linux-gnueabi: ARM's "new" GNU EABI for Linux, soft float, 32 bit.
	Documented at http://wiki.debian.org/ArmEabiPort which refers to
	http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042a/IHI0042A_aapcs.pdf
	http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf

 arm-linux-gnueabihf: likewise but with hard float




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Mon, 19 Mar 2012 13:54:30 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Mon, 19 Mar 2012 13:54:38 GMT) Full text and rfc822 format available.

Message #15 received at 664257@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 664257@bugs.debian.org, Matthias Klose <doko@debian.org>
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Mon, 19 Mar 2012 14:53:14 +0100
Jonathan Nieder <jrnieder@gmail.com> writes:

> Matthias Klose wrote:
>
>> While we strive to get multiarch ready for squeeze, there is
>> currently nothing to point to what the multiarch tuples actually
>> mean, neither on the Debian side nor on some kind of standards side
>> like the FHS or LSB.  This has to be documented on the Debian side,
>> and better be incorporated into standards like the FHS or LSB.
>>
>> The current state is http://wiki.debian.org/Multiarch/Tuples,
>> deriving from http://wiki.debian.org/Multiarch/TuplesAbandoned. An
>> email to debian-ports didn't get any feedback. From my point of view
>> such a wiki page should be self-contained and be usable as a
>> reference for upstream projects.
>
> Thanks.  To start (warning: the following is just a bunch of guesses,
> many of which are almost certainly wrong):

Did you read the wiki page?

If I had to define the multiarch tuple I would say:

The multiarch tuple uniquly defines the calling convention used in a
binary or library. For convenience the first GNU triplet implementing a
calling convention is used where possible or suitably extended to remain
unique.

If there are multiple libraries with different ABIs but with the same
calling convention (e.g. i386, i486, i586, ...) so that they can be
interchanged without binaries needing to be recompiled then they share a
multiarch tuple (i386-linux-gnu).

On the other hand if one ABI has multiple calling conventions (hard/soft
floats on arm) then the multiarch tuples must differ for each calling
convention.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Mon, 19 Mar 2012 14:36:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Mon, 19 Mar 2012 14:36:18 GMT) Full text and rfc822 format available.

Message #20 received at 664257@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 664257@bugs.debian.org, Matthias Klose <doko@debian.org>
Subject: Re: multiarch tuples are not documented/defined
Date: Mon, 19 Mar 2012 09:34:23 -0500
Goswin von Brederlow wrote:

> Did you read the wiki page?

Yes.  Is the kind of information on which calling convention, basic
system library structures, and so on form the ABI for a given tuple
that I was giving examples of not what the upstream gcc folks were
looking for?  I'm not sure I understand the point of your question.

Ah, maybe this is where we are talking past each other: I read this as
a request to pin down and document the definition of each multiarch
tuple.  Perhaps you read it as a request to pin down and document the
definition of the term "multiarch tuple", without necessarily pinning
down the details for each arch.

It would certainly be useful to clarify which is needed before
deciding which to spend time on, so thanks for asking.  Matthias?

Thanks for a useful clarification.
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Mon, 19 Mar 2012 14:54:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Mon, 19 Mar 2012 14:54:06 GMT) Full text and rfc822 format available.

Message #25 received at 664257@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, 664257@bugs.debian.org
Subject: Re: multiarch tuples are not documented/defined
Date: Mon, 19 Mar 2012 15:50:31 +0100
On 19.03.2012 15:34, Jonathan Nieder wrote:
> Goswin von Brederlow wrote:
>
>> Did you read the wiki page?
>
> Yes.  Is the kind of information on which calling convention, basic
> system library structures, and so on form the ABI for a given tuple
> that I was giving examples of not what the upstream gcc folks were
> looking for?  I'm not sure I understand the point of your question.
>
> Ah, maybe this is where we are talking past each other: I read this as
> a request to pin down and document the definition of each multiarch
> tuple.  Perhaps you read it as a request to pin down and document the
> definition of the term "multiarch tuple", without necessarily pinning
> down the details for each arch.
>
> It would certainly be useful to clarify which is needed before
> deciding which to spend time on, so thanks for asking.  Matthias?

first thing would be the documentation of each tuple currently used by Debian 
(including the ones used for the non-default biarch multilibs). If we can come 
up with a definition of "multiarch tuple" later that's fine, but given that we 
did abandon the earlier approach I'm not sure that's possible.

  Matthias





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Wed, 21 Mar 2012 10:30:28 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 21 Mar 2012 10:30:34 GMT) Full text and rfc822 format available.

Message #30 received at 664257@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Matthias Klose <doko@debian.org>
Cc: Jonathan Nieder <jrnieder@gmail.com>, Goswin von Brederlow <goswin-v-b@web.de>, 664257@bugs.debian.org
Subject: Re: multiarch tuples are not documented/defined
Date: Wed, 21 Mar 2012 11:26:46 +0100
Matthias Klose <doko@debian.org> writes:

> On 19.03.2012 15:34, Jonathan Nieder wrote:
>> Goswin von Brederlow wrote:
>>
>>> Did you read the wiki page?
>>
>> Yes.  Is the kind of information on which calling convention, basic
>> system library structures, and so on form the ABI for a given tuple
>> that I was giving examples of not what the upstream gcc folks were
>> looking for?  I'm not sure I understand the point of your question.
>>
>> Ah, maybe this is where we are talking past each other: I read this as
>> a request to pin down and document the definition of each multiarch
>> tuple.  Perhaps you read it as a request to pin down and document the
>> definition of the term "multiarch tuple", without necessarily pinning
>> down the details for each arch.
>>
>> It would certainly be useful to clarify which is needed before
>> deciding which to spend time on, so thanks for asking.  Matthias?
>
> first thing would be the documentation of each tuple currently used by
> Debian (including the ones used for the non-default biarch
> multilibs). If we can come up with a definition of "multiarch tuple"
> later that's fine, but given that we did abandon the earlier approach
> I'm not sure that's possible.
>
>   Matthias

Should we even have biarch in the multiarch world?

The biarch libs and foreign libs installed through multiarch implement
the same ABI/calling convention/functionality. They are basically
interchangable.

To make them truely interchangable the multiarch tuple for biarch libs
should be the same as they would have if they were the native
one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as
example from now on]. And they should use the same paths. If there is no
native equivalent for some biarch lib then just make up some multiarch
tuple based on the gnu triplet. The only thing that matters is that it
uniquly identifies the calling convention of the lib.


For Debian (wheezy+x) I would like to see gcc-multilib depend on
libc6:i386 instead of libc6-i386. Or maybe remove multilib support
alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc
-m32 could remain for compatibility but call i486-linux-gnu-gcc.

After all with multiarch having anything build for 32bit in amd64 is
wastefull as it just duplicates the package already in i386. Same with
ppc / ppc64, ...

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Wed, 21 Mar 2012 14:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 21 Mar 2012 14:33:05 GMT) Full text and rfc822 format available.

Message #35 received at 664257@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Goswin von Brederlow <goswin-v-b@web.de>, 664257@bugs.debian.org
Cc: Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Wed, 21 Mar 2012 15:30:26 +0100
On 21.03.2012 11:26, Goswin von Brederlow wrote:
> Matthias Klose<doko@debian.org>  writes:
>
>> On 19.03.2012 15:34, Jonathan Nieder wrote:
>>> Goswin von Brederlow wrote:
>>>
>>>> Did you read the wiki page?
>>>
>>> Yes.  Is the kind of information on which calling convention, basic
>>> system library structures, and so on form the ABI for a given tuple
>>> that I was giving examples of not what the upstream gcc folks were
>>> looking for?  I'm not sure I understand the point of your question.
>>>
>>> Ah, maybe this is where we are talking past each other: I read this as
>>> a request to pin down and document the definition of each multiarch
>>> tuple.  Perhaps you read it as a request to pin down and document the
>>> definition of the term "multiarch tuple", without necessarily pinning
>>> down the details for each arch.
>>>
>>> It would certainly be useful to clarify which is needed before
>>> deciding which to spend time on, so thanks for asking.  Matthias?
>>
>> first thing would be the documentation of each tuple currently used by
>> Debian (including the ones used for the non-default biarch
>> multilibs). If we can come up with a definition of "multiarch tuple"
>> later that's fine, but given that we did abandon the earlier approach
>> I'm not sure that's possible.
>>
>>    Matthias
>
> Should we even have biarch in the multiarch world?

multilib libraries should continue to build.

> The biarch libs and foreign libs installed through multiarch implement
> the same ABI/calling convention/functionality. They are basically
> interchangable.
>
> To make them truely interchangable the multiarch tuple for biarch libs
> should be the same as they would have if they were the native
> one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as
> example from now on]. And they should use the same paths. If there is no
> native equivalent for some biarch lib then just make up some multiarch
> tuple based on the gnu triplet. The only thing that matters is that it
> uniquly identifies the calling convention of the lib.
>
>
> For Debian (wheezy+x) I would like to see gcc-multilib depend on
> libc6:i386 instead of libc6-i386.  Or maybe remove multilib support
> alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc
> -m32 could remain for compatibility but call i486-linux-gnu-gcc.

no. adding cross-architecture build dependencies doesn't add to the build 
stability. The possibility to call another version or target compiler from the 
driver was removed upstream, so I doubt somebody want to re-add it again, and I 
won't carry this as a downstream patch (so please get the done in stage1 for 4.8 
if you are interested in that).

> After all with multiarch having anything build for 32bit in amd64 is
> wastefull as it just duplicates the package already in i386. Same with
> ppc / ppc64, ...

yes, but you are quick to waste my own time. Patches which do not go upstream do 
require an extra maintenance effort as seen for the split build (gcc, gcj, ...) 
and the hardening patches.  A lot of multilib packages can be dropped,
but the ones built from gcc and glibc should continue to build.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Thu, 22 Mar 2012 17:15:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 22 Mar 2012 17:15:03 GMT) Full text and rfc822 format available.

Message #40 received at 664257@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Matthias Klose <doko@debian.org>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, 664257@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Thu, 22 Mar 2012 18:14:01 +0100
Matthias Klose <doko@debian.org> writes:

> On 21.03.2012 11:26, Goswin von Brederlow wrote:
>> Matthias Klose<doko@debian.org>  writes:
>>
>>> On 19.03.2012 15:34, Jonathan Nieder wrote:
>>>> Goswin von Brederlow wrote:
>>>>
>>>>> Did you read the wiki page?
>>>>
>>>> Yes.  Is the kind of information on which calling convention, basic
>>>> system library structures, and so on form the ABI for a given tuple
>>>> that I was giving examples of not what the upstream gcc folks were
>>>> looking for?  I'm not sure I understand the point of your question.
>>>>
>>>> Ah, maybe this is where we are talking past each other: I read this as
>>>> a request to pin down and document the definition of each multiarch
>>>> tuple.  Perhaps you read it as a request to pin down and document the
>>>> definition of the term "multiarch tuple", without necessarily pinning
>>>> down the details for each arch.
>>>>
>>>> It would certainly be useful to clarify which is needed before
>>>> deciding which to spend time on, so thanks for asking.  Matthias?
>>>
>>> first thing would be the documentation of each tuple currently used by
>>> Debian (including the ones used for the non-default biarch
>>> multilibs). If we can come up with a definition of "multiarch tuple"
>>> later that's fine, but given that we did abandon the earlier approach
>>> I'm not sure that's possible.
>>>
>>>    Matthias
>>
>> Should we even have biarch in the multiarch world?
>
> multilib libraries should continue to build.

Time will tell.

>> The biarch libs and foreign libs installed through multiarch implement
>> the same ABI/calling convention/functionality. They are basically
>> interchangable.
>>
>> To make them truely interchangable the multiarch tuple for biarch libs
>> should be the same as they would have if they were the native
>> one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as
>> example from now on]. And they should use the same paths. If there is no
>> native equivalent for some biarch lib then just make up some multiarch
>> tuple based on the gnu triplet. The only thing that matters is that it
>> uniquly identifies the calling convention of the lib.
>>
>>
>> For Debian (wheezy+x) I would like to see gcc-multilib depend on
>> libc6:i386 instead of libc6-i386.  Or maybe remove multilib support
>> alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc
>> -m32 could remain for compatibility but call i486-linux-gnu-gcc.
>
> no. adding cross-architecture build dependencies doesn't add to the
> build stability. The possibility to call another version or target

Nobody is talking about cross-architecture build dependencies.

As said building 32bit stuff on amd64 in the multiarch world is
pointless. The same stuff can just be gotten from i386 directly.

And if no source builds 32bit stuff on amd64 then we do not need
multilib.

And if nothing needs multilib then you do not need to build it and thus
do not need to build-depend on cross-architecture stuff to build it.

> compiler from the driver was removed upstream, so I doubt somebody
> want to re-add it again, and I won't carry this as a downstream patch
> (so please get the done in stage1 for 4.8 if you are interested in
> that).

Fair enough. Overall it would make no sense that I have to call
armel-linux-gnu-gcc to build for arm but gcc -m32 to build for i386 in a
multiarch world [again example with amd64 as native arch].

>> After all with multiarch having anything build for 32bit in amd64 is
>> wastefull as it just duplicates the package already in i386. Same with
>> ppc / ppc64, ...
>
> yes, but you are quick to waste my own time. Patches which do not go
> upstream do require an extra maintenance effort as seen for the split
> build (gcc, gcj, ...) and the hardening patches.  A lot of multilib
> packages can be dropped,
> but the ones built from gcc and glibc should continue to build.

Nobody is holding a gun to your head and forcing you to invest any
time. Although I would say dropping multilib would rather safe you a lot
of time and maintainance effort than cost you anything. And since
multilib is enabled in debian/* there is no patch that would need to go
upstream.

Wheezy+x is a long way in the future so lets just wait and see. There is
still a lot of work to do for multiarch before dropping multilib support
from gcc can even be considered. No point arguing about that now.

MfG
        Goswin





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Wed, 11 Apr 2012 17:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve McIntyre <steve.mcintyre@linaro.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 11 Apr 2012 17:03:07 GMT) Full text and rfc822 format available.

Message #45 received at 664257@bugs.debian.org (full text, mbox):

From: Steve McIntyre <steve.mcintyre@linaro.org>
To: Matthias Klose <doko@debian.org>, 664257@bugs.debian.org
Cc: michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Wed, 11 Apr 2012 18:00:35 +0100
On Sat, Mar 17, 2012 at 07:03:09AM +0100, Matthias Klose wrote:
>Package: general
>Severity: serious
>Tags: wheezy, sid
>
>While we strive to get multiarch ready for squeeze, there is
>currently nothing to point to what the multiarch tuples actually
>mean, neither on the Debian side nor on some kind of standards side
>like the FHS or LSB.  This has to be documented on the Debian side,
>and better be incorporated into standards like the FHS or LSB.
>
>The current state is http://wiki.debian.org/Multiarch/Tuples,
>deriving from http://wiki.debian.org/Multiarch/TuplesAbandoned. An
>email to debian-ports didn't get any feedback. From my point of view
>such a wiki page should be self-contained and be usable as a
>reference for upstream projects.  My current concern is that upstream
>builds of GCC and binutils are currently broken and patch submissions
>to GCC are on hold until such a definition is available at least on
>the Debian side.

I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
information such as links to external ABI specs where I could find
them. I based this on Jonathan Nieder's initial email (thanks!) and
filled in from there. For the non-Linux ports a bit more help would be
useful; I don't know where the Hurd/kFreeBSD ports are specified
externally, if indeed they are at all.

Review/comments/corrections welcome. I hope this helps with what
you're looking for, Matthias?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim."          [ seen in ucam.chat ]





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Wed, 18 Apr 2012 03:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 18 Apr 2012 03:21:06 GMT) Full text and rfc822 format available.

Message #50 received at 664257@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Matthias Klose <doko@debian.org>
Cc: Steve McIntyre <steve.mcintyre@linaro.org>, 664257@bugs.debian.org, michael.hope@linaro.org
Subject: Re: multiarch tuples are not documented/defined
Date: Tue, 17 Apr 2012 22:16:51 -0500
Hi Matthias,

Steve McIntyre wrote:

> I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
> information such as links to external ABI specs where I could find
> them.

I think the Multiarch/Tuples wiki page is now in a sane state, though
as always it could presumably be improved even more.  I think future
required improvements can be tracked separately.  Do you mind if this
bug is closed?

Thanks much,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Wed, 18 Apr 2012 13:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 18 Apr 2012 13:57:06 GMT) Full text and rfc822 format available.

Message #55 received at 664257@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 664257@bugs.debian.org
Cc: Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Wed, 18 Apr 2012 15:51:59 +0200
severity 664257 important
thanks

On 18.04.2012 05:16, Jonathan Nieder wrote:
> Hi Matthias,
> 
> Steve McIntyre wrote:
> 
>> I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
>> information such as links to external ABI specs where I could find
>> them.
> 
> I think the Multiarch/Tuples wiki page is now in a sane state, though
> as always it could presumably be improved even more.  I think future
> required improvements can be tracked separately.  Do you mind if this
> bug is closed?

lowered the severity. IMO it should stay open until multiarch is incorporated
into the FHS and/or the LSB.

  Matthias




Severity set to 'important' from 'serious' Request was from Matthias Klose <doko@debian.org> to control@bugs.debian.org. (Wed, 18 Apr 2012 13:57:15 GMT) Full text and rfc822 format available.

Changed Bug title to 'multiarch tuples are not in the FHS' from 'multiarch tuples are not documented/defined' Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Wed, 18 Apr 2012 15:54:03 GMT) Full text and rfc822 format available.

Added tag(s) upstream. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Wed, 18 Apr 2012 15:54:03 GMT) Full text and rfc822 format available.

Added indication that 664257 affects debian-policy Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Wed, 18 Apr 2012 15:54:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Fri, 20 Apr 2012 14:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 20 Apr 2012 14:57:03 GMT) Full text and rfc822 format available.

Message #68 received at 664257@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Matthias Klose <doko@debian.org>, 664257@bugs.debian.org
Cc: Jonathan Nieder <jrnieder@gmail.com>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Fri, 20 Apr 2012 15:55:09 +0100
Matthias Klose writes ("Bug#664257: multiarch tuples are not documented/defined"):
> On 18.04.2012 05:16, Jonathan Nieder wrote:
> > I think the Multiarch/Tuples wiki page is now in a sane state, though
> > as always it could presumably be improved even more.  I think future
> > required improvements can be tracked separately.  Do you mind if this
> > bug is closed?
> 
> lowered the severity. IMO it should stay open until multiarch is incorporated
> into the FHS and/or the LSB.

We do not normally keep a bug open in the Debian BTS that cannot be
fixed in Debian.

What change to the Debian operating system, or to processes,
documents, infrastructure or organisational arrangements, maintained
by the Debian project, is this bug requesting ?

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Fri, 20 Apr 2012 15:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 20 Apr 2012 15:09:05 GMT) Full text and rfc822 format available.

Message #73 received at 664257@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 664257@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Fri, 20 Apr 2012 17:04:42 +0200
On 20.04.2012 16:55, Ian Jackson wrote:
> Matthias Klose writes ("Bug#664257: multiarch tuples are not documented/defined"):
>> On 18.04.2012 05:16, Jonathan Nieder wrote:
>>> I think the Multiarch/Tuples wiki page is now in a sane state, though
>>> as always it could presumably be improved even more.  I think future
>>> required improvements can be tracked separately.  Do you mind if this
>>> bug is closed?
>>
>> lowered the severity. IMO it should stay open until multiarch is incorporated
>> into the FHS and/or the LSB.
> 
> We do not normally keep a bug open in the Debian BTS that cannot be
> fixed in Debian.
> 
> What change to the Debian operating system, or to processes,
> documents, infrastructure or organisational arrangements, maintained
> by the Debian project, is this bug requesting ?

I won't fight for this. But it's some kind of Debian responsibility to
address/forward these.  Just filing this with the FHS and/or LSB is likely
getting ignored.  If you have better ways to track progress with this issue,
please tell here.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Fri, 20 Apr 2012 20:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 20 Apr 2012 20:39:03 GMT) Full text and rfc822 format available.

Message #78 received at 664257@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: 664257@bugs.debian.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Fri, 20 Apr 2012 22:35:52 +0200
]] Matthias Klose 

> I won't fight for this. But it's some kind of Debian responsibility to
> address/forward these.  Just filing this with the FHS and/or LSB is likely
> getting ignored.  If you have better ways to track progress with this issue,
> please tell here.

JFTR, the FHS and the LSB has a bug tracker, so while filing those might
does not guarantee they'll be fixed, it won't just get dropped on the
floor either.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Wed, 25 Apr 2012 09:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 25 Apr 2012 09:21:13 GMT) Full text and rfc822 format available.

Message #83 received at 664257@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 664257@bugs.debian.org, Matthias Klose <doko@debian.org>, Jonathan Nieder <jrnieder@gmail.com>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Wed, 25 Apr 2012 11:19:36 +0200
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Matthias Klose writes ("Bug#664257: multiarch tuples are not documented/defined"):
>> On 18.04.2012 05:16, Jonathan Nieder wrote:
>> > I think the Multiarch/Tuples wiki page is now in a sane state, though
>> > as always it could presumably be improved even more.  I think future
>> > required improvements can be tracked separately.  Do you mind if this
>> > bug is closed?
>> 
>> lowered the severity. IMO it should stay open until multiarch is incorporated
>> into the FHS and/or the LSB.
>
> We do not normally keep a bug open in the Debian BTS that cannot be
> fixed in Debian.
>
> What change to the Debian operating system, or to processes,
> documents, infrastructure or organisational arrangements, maintained
> by the Debian project, is this bug requesting ?
>
> Ian.

Aren't the Upstream and Forwarded tags exactly for this situation?

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Wed, 25 Apr 2012 13:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 25 Apr 2012 13:48:05 GMT) Full text and rfc822 format available.

Message #88 received at 664257@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 664257@bugs.debian.org, Matthias Klose <doko@debian.org>, Jonathan Nieder <jrnieder@gmail.com>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Wed, 25 Apr 2012 14:46:19 +0100
Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not documented/defined"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > What change to the Debian operating system, or to processes,
> > documents, infrastructure or organisational arrangements, maintained
> > by the Debian project, is this bug requesting ?
...
> Aren't the Upstream and Forwarded tags exactly for this situation?

No.

Upstream means that we agree that the problem is a bug in Debian, but
that the bug is also in the upstream code - ie, we have inherited it
from upstream.

Forwarded means that we agree that the problem is a bug in Debian; we
think that the best way to fix it is to engage with upstream (and
perhaps take their fix in due course, or perhaps cherry pick it); and
we have therefore notified upstream via their bug tracker.

These overlap.  Normally Forwarded would imply Upstream although I
guess there might be bizarre situations where we would (for example)
ask for upstream help or advice with fixing a bug which manifests only
in Debian.

But neither of them is appropriate if the bug cannot be fixed by any
change in Debian (a package, process, document, or whatever).

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Thu, 26 Apr 2012 23:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 26 Apr 2012 23:03:03 GMT) Full text and rfc822 format available.

Message #93 received at 664257@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, 664257@bugs.debian.org, Matthias Klose <doko@debian.org>, Jonathan Nieder <jrnieder@gmail.com>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Fri, 27 Apr 2012 00:58:08 +0200
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not documented/defined"):
>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> > What change to the Debian operating system, or to processes,
>> > documents, infrastructure or organisational arrangements, maintained
>> > by the Debian project, is this bug requesting ?
> ...
>> Aren't the Upstream and Forwarded tags exactly for this situation?
>
> No.
>
> Upstream means that we agree that the problem is a bug in Debian, but
> that the bug is also in the upstream code - ie, we have inherited it
> from upstream.
>
> Forwarded means that we agree that the problem is a bug in Debian; we
> think that the best way to fix it is to engage with upstream (and
> perhaps take their fix in due course, or perhaps cherry pick it); and
> we have therefore notified upstream via their bug tracker.

It is a bug in Debian: The multiarch tuples are not documented/defined
in Debian.

The bug is also in the upstream code since upstream does not document
the tuples and we inherited that from them.

So the bug should be reported in upstreams BTS and then tagged as
forwarded. Once they add the multiarch tuples we can cherry pick that or
wait for the next release. That all seems to fit perfectly with your
description.

Ok, we also created the problem by inventing the multiarch tuples. But
still, we want upstream to fix this and don't want to diverge from
them.

> These overlap.  Normally Forwarded would imply Upstream although I
> guess there might be bizarre situations where we would (for example)
> ask for upstream help or advice with fixing a bug which manifests only
> in Debian.
>
> But neither of them is appropriate if the bug cannot be fixed by any
> change in Debian (a package, process, document, or whatever).
>
> Ian.

I don't agree with that. Where does it say that and how is that usefull?

For one thing a bug can always be fixed in Debian wth enough work if it
is fixable at all. It just might not be the right thing to do. For
example the multiarch tuples could be added to Debian policy with the
proper exceptions to the FHS and so on.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#664257; Package general. (Thu, 26 Apr 2012 23:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 26 Apr 2012 23:27:06 GMT) Full text and rfc822 format available.

Message #98 received at 664257@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, 664257@bugs.debian.org, Matthias Klose <doko@debian.org>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org, debian-policy@lists.debian.org
Subject: Re: multiarch tuples are not documented/defined
Date: Thu, 26 Apr 2012 18:25:26 -0500
reassign 664257 debian-policy 3.9.3.1
affects 664257 =
tags 664257 = upstream
quit

Goswin von Brederlow wrote:

> It is a bug in Debian: The multiarch tuples are not documented/defined
> in Debian.

Fine, reassigning to policy.

Never say I didn't do anything for you... :)

Policy maintainers, see http://wiki.debian.org/Multiarch/Tuples for a
nice table to incorporate.  Ultimately we would like to see this,
along with some more text to make it precise, in some LSB document
such as the FHS.

Thanks for your work, and hope that helps,
Jonathan




Bug reassigned from package 'general' to 'debian-policy'. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 26 Apr 2012 23:27:07 GMT) Full text and rfc822 format available.

Marked as found in versions debian-policy/3.9.3.1. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 26 Apr 2012 23:27:08 GMT) Full text and rfc822 format available.

Removed indication that 664257 affects debian-policy Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 26 Apr 2012 23:27:09 GMT) Full text and rfc822 format available.

Removed tag(s) sid and wheezy. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 26 Apr 2012 23:27:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#664257; Package debian-policy. (Thu, 26 Apr 2012 23:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 26 Apr 2012 23:33:03 GMT) Full text and rfc822 format available.

Message #111 received at 664257@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 664257@bugs.debian.org, Matthias Klose <doko@debian.org>, Jonathan Nieder <jrnieder@gmail.com>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Fri, 27 Apr 2012 00:31:33 +0100
Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not documented/defined"):
> It is a bug in Debian: The multiarch tuples are not documented/defined
> in Debian.

They are now documented on the wiki, as previously noted in this
thread.

> The bug is also in the upstream code since upstream does not document
> the tuples and we inherited that from them.

I'm not sure exactly what you mean.  In which upstream package,
shipped by Debian, do you think this documentation should be ?
Are you saying that this bug report should now be regarded as a
request to move the documentation from the wiki to some source 
package ?

> For one thing a bug can always be fixed in Debian wth enough work if it
> is fixable at all. [...]

Should I file a bug in the Debian BTS about the fact that my
employer's Microsoft Exchange server corrupts emails ?

I really don't see the difference, in principle ...

To be honest what I mostly seem to understand from your contributions
to this bug a general but rather unfocused hostility to multiarch.  It
is of course fine for you not to like multiarch.  But the purpose of
the BTS is not to be an outlet for gripes; if it were I have plenty of
my own.  The purpose of the BTS is for us to track specific problems,
the correction of which lies in our power.

But I'm wasting too much of everyone's time arguing about the state of
this now-non-bug.  It would be better just to let it sit and rot in
the BTS so this will be my last message here.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#664257; Package debian-policy. (Fri, 27 Apr 2012 00:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Apr 2012 00:09:07 GMT) Full text and rfc822 format available.

Message #116 received at 664257@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 664257@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Thu, 26 Apr 2012 17:06:02 -0700
Trimming the cc list down to something somewhat less large.

Jonathan Nieder <jrnieder@gmail.com> writes:
> Goswin von Brederlow wrote:

>> It is a bug in Debian: The multiarch tuples are not documented/defined
>> in Debian.

> Fine, reassigning to policy.

> Never say I didn't do anything for you... :)

> Policy maintainers, see http://wiki.debian.org/Multiarch/Tuples for a
> nice table to incorporate.  Ultimately we would like to see this,
> along with some more text to make it precise, in some LSB document
> such as the FHS.

My opinion is the same as Ian's: I'm not going to hold a bug open waiting
for LSB to incorporate something.  If this table should go into Debian
Policy (which at first glance seems like a reasonable idea), then that
will be the criteria for closing the bug.  If people want to bring this
forward with LSB, a bug against debian-policy is not the mechanism for
doing that.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#664257; Package debian-policy. (Fri, 27 Apr 2012 06:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Apr 2012 06:45:03 GMT) Full text and rfc822 format available.

Message #121 received at 664257@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 664257@bugs.debian.org
Subject: Re: multiarch tuples are not documented/defined
Date: Fri, 27 Apr 2012 01:41:01 -0500
Hi Russ et al,

The patch below documents the Architecture field.  It doesn't cover
architecture tuples yet, but presumably once the description of
architectures is in good shape it would not be hard to add a mapping
from Debian arches to pathnames to section 9.1.5.

Some concerns:

 - what should the normative content be?  It would not be too strange
   to put a firmware file that happens to be a MIPS binary in an
   "Architecture: i386" or "Architecture: all" package, and I think
   it is important to keep permitting that.

   How should this be worded to permit that sort of thing while still
   making it clear that a package installing MIPS DSOs as NSS plugins
   under /usr/lib/nss ought to use architecture: mips or mipsel?

 - what happens if an ABI document is just wrong?  (For example, I
   have no idea whether the m68k psABI is accurate.)

 - the notion of ABI in the multiarch sense is surprisingly
   slippery.  Corrections and clarifications to the definition used
   below could be useful --- the important notion of "which objects
   can share a process image?" didn't manage to find its way in.

 - is it okay to rely so heavily on external resources?  Is it safe to
   assume that the reader can look up link targets when needed, or
   does link text need to be unambiguous?  Would we need to include a
   summary or copy of some of the cited standards in case they
   disappear?

I didn't include the full table from [1], though it might make a nice
appendix.  If the text is working as it ought to, then it should be
possible to infer the omitted values (endianness, sizeof(long), and so
on) from the descriptions below.

My hope is that this documentation might make it easier to explain the
purpose and semantics of the Multiarch: field later.

Improvements welcome, of course.  What do you think?

[1] http://wiki.debian.org/Multiarch/Tuples

 policy.sgml |  192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 191 insertions(+), 1 deletion(-)

diff --git a/policy.sgml b/policy.sgml
index 52dbb26a..1a7ed748 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1423,6 +1423,25 @@
 
       </sect>
 
+      <sect id="architecture">
+	<heading>Architecture</heading>
+
+	<p>
+	  Every Debian binary package must have an <tt>Architecture</tt>
+	  control field which describes the ABI used by dynamically-linked
+	  binaries and public shared libraries in the package and
+	  packages it interacts with.  For example, packages built to run
+	  on a 32-bit Intel-architecture GNU/Linux system would use an
+	  <tt>Architecture</tt> of <tt>i386</tt>.
+	</p>
+
+	<p>
+	  Unless otherwise specified, dependencies specified using the
+	  <tt>Suggests</tt>, <tt>Depends</tt>, <tt>Recommends</tt>, and
+	  <tt>Pre-Depends</tt> fields refer to packages of the same
+	  architecture.
+	</p>
+      </sect>
     </chapt>
 
 
@@ -2945,7 +2964,7 @@ Package: libc6
 	    <list>
 		<item>
 		  A unique single word identifying a Debian machine
-		  architecture as described in <ref id="arch-spec">.
+		  architecture as described in <ref id="arch-short-name">.
 		</item>
 		<item>
 		  An architecture wildcard identifying a set of Debian
@@ -3052,6 +3071,177 @@ Package: libc6
 	    See <ref id="debianrules"> for information on how to get
 	    the architecture for the build process.
 	  </p>
+
+	  <sect2 id="arch-short-name">
+	    <heading>Debian architecture names</heading>
+
+	    <p>
+	      Binary programs and public shared libraries in binary
+	      packages must use the appropriate binary format,
+	      basic operating system interface, and procedure linkage
+	      convention declared in the <tt>Architecture</tt> field.
+	      <footnote>
+		The <tt>Architecture</tt> field indicates the system
+		ABI but not the precise instruction set or system
+		libraries used: the former is generally determined by
+		convention with exceptions noted in the package
+		description or using hwcap paths, and the latter
+		expressed using package dependencies.
+	      </footnote>
+	    </p>
+
+	    <p>
+	      <taglist>
+		<tag><tt>alpha</tt></tag>
+		<item>
+		  GNU/Linux,
+		  <url id="http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/ARH9MBTE/TITLE.HTM"
+		    name="Tru64 5.1 Calling Standard for Alpha Systems">
+		</item>
+
+		<tag><tt>arm</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="http://infocenter.arm.com/help/topic/com.arm.doc.dui0041c/BGBGFIDA.html"
+		    name="ARM Procedure Call Standard (obsolete)">
+		</item>
+
+		<tag><tt>armel</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="https://sourcery.mentor.com/GNUToolchain/kbentry39"
+		    name="ARM GNU/Linux ABI 1.0">
+		</item>
+
+		<tag><tt>armhf</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="https://sourcery.mentor.com/GNUToolchain/kbentry39"
+		    name="ARM GNU/Linux ABI 1.0">,
+		  except that function calls use VFP Register Arguments
+		  as described in the
+		  <url id="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042a/IHI0042A_aapcs.pdf"
+		    name="Procedure Call Standard for the ARM Architecture">,
+		  section 6.
+		</item>
+
+		<tag><tt>hppa</tt></tag>
+		<item>
+		  <url id="http://wiki.parisc-linux.org/ToolChain"
+		    name="PA-RISC Linux 32-bit ELF">
+		</item>
+
+		<tag><tt>hurd-i386</tt></tag>
+		<item>
+		  GNU/Hurd,
+		  <url id="http://refspecs.linuxbase.org/elf/abi386-4.pdf"
+		    name="Intel IA-32 psABI">,
+		  16-byte stack alignment
+		</item>
+
+		<tag><tt>kfreebsd-i386</tt></tag>
+		<item>
+		  GNU/kernel of FreeBSD,
+		  <url id="http://refspecs.linuxbase.org/elf/abi386-4.pdf"
+		    name="Intel IA-32 psABI">,
+		  16-byte stack alignment
+		</item>
+
+		<tag><tt>i386</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-IA32/LSB-Core-IA32/elf-ia32.html"
+		    name="LSB IA32 4.1">,
+		  16-byte stack alignment
+		</item>
+
+		<tag><tt>ia64</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-IA64/LSB-Core-IA64/elf-ia64.html"
+		    name="LSB IA64 4.1">
+		</item>
+
+		<tag><tt>m68k</tt></tag>
+		<item>
+		  GNU/Linux, Motorola 68000 psABI (ISBN 978-0138776633)
+		</item>
+
+		<tag><tt>mips</tt></tag>
+		<item>
+		  GNU/Linux, big endian,
+		  <url id="http://refspecs.linuxbase.org/elf/mipsabi.pdf"
+		    name="MIPS o32 ABI">
+		</item>
+
+		<tag><tt>mipsel</tt></tag>
+		<item>
+		  GNU/Linux, little endian,
+		  <url id="http://refspecs.linuxbase.org/elf/mipsabi.pdf"
+		    name="MIPS o32 ABI">
+		</item>
+
+		<tag><tt>powerpc</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC32/LSB-Core-PPC32/elf-ppc32.html"
+		    name="LSB PPC32 4.1">
+		</item>
+
+		<tag><tt>powerpcspe</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC32/LSB-Core-PPC32/elf-ppc32.html"
+		    name="LSB PPC32 4.1">,
+		  except that function calls and relocations use the e500
+		  convention described in the ATR-SPE portion of the
+		  <url id="https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0.tgz"
+		    name="Power Architecture 32-bit ABI Supplement 1.0">
+		</item>
+
+		<tag><tt>ppc64</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-PPC64/LSB-Core-PPC64/elf-ppc64.html"
+		    name="LSB PPC64 4.1">
+		</item>
+
+		<tag><tt>s390</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-S390/LSB-Core-S390/elf-s390.html"
+		    name="LSB S390 4.1">
+		</item>
+
+		<tag><tt>s390x</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-S390X/LSB-Core-S390X/elf-s390x.html"
+		    name="LSB S390X 4.1">
+		</item>
+
+		<tag><tt>sparc</tt></tag>
+		<item>
+		GNU/Linux,
+		  <url id="http://www.sparc.com/standards/psABI3rd.pdf"
+		    name="32-bit SPARC psABI">
+		</item>
+
+		<tag><tt>sparc64</tt></tag>
+		<item>
+		  GNU/Linux,
+		  <url id="http://www.sparc.com/standards/64.psabi.1.35.ps.Z"
+		    name="64-bit SPARCv9 psABI">
+		</item>
+
+		<tag><tt>kfreebsd-amd64</tt></tag>
+		<item>
+		  GNU/kernel of FreeBSD,
+		  <url id="http://x86-64.org/documentation/abi.pdf"
+		    name="AMD64 psABI">
+		</item>
+
+		<tag><tt>amd64</tt></tag>
+		<item>
+		  <url id="http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-AMD64/LSB-Core-AMD64/elf-amd64.html"
+		    name="LSB AMD64 4.1">
+		</item>
+	      </taglist>
+	    </p>
+	  </sect2>
 	</sect1>
 
 	<sect1 id="f-Essential">
-- 
1.7.10





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#664257; Package debian-policy. (Fri, 27 Apr 2012 08:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Apr 2012 08:30:03 GMT) Full text and rfc822 format available.

Message #126 received at 664257@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: Goswin von Brederlow <goswin-v-b@web.de>, 664257@bugs.debian.org, Matthias Klose <doko@debian.org>, Jonathan Nieder <jrnieder@gmail.com>, Steve McIntyre <steve.mcintyre@linaro.org>, michael.hope@linaro.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Fri, 27 Apr 2012 10:27:16 +0200
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not documented/defined"):
>> It is a bug in Debian: The multiarch tuples are not documented/defined
>> in Debian.
>
> They are now documented on the wiki, as previously noted in this
> thread.
>
>> The bug is also in the upstream code since upstream does not document
>> the tuples and we inherited that from them.
>
> I'm not sure exactly what you mean.  In which upstream package,
> shipped by Debian, do you think this documentation should be ?
> Are you saying that this bug report should now be regarded as a
> request to move the documentation from the wiki to some source 
> package ?

Yes, like Jonathan wrote:

Jonathan Nieder <jrnieder@gmail.com> writes:

>> It is a bug in Debian: The multiarch tuples are not documented/defined
>> in Debian.
>
> Fine, reassigning to policy.
>
> Never say I didn't do anything for you... :)
>
> Policy maintainers, see http://wiki.debian.org/Multiarch/Tuples for a
> nice table to incorporate.  Ultimately we would like to see this,
> along with some more text to make it precise, in some LSB document
> such as the FHS.
>
> Thanks for your work, and hope that helps,
> Jonathan

I was more thinking along the line of forwarded, as in filing it in the
upstream BTS someone mentioned before and getting in touch with the FHS
people and convince them to add them. Obviously just setting the tag
alone is not doing anything to resolve the issue.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

>> For one thing a bug can always be fixed in Debian wth enough work if it
>> is fixable at all. [...]
>
> Should I file a bug in the Debian BTS about the fact that my
> employer's Microsoft Exchange server corrupts emails ?
>
> I really don't see the difference, in principle ...

The difference is that Debian does not contain Microsoft Exchange but it
does contain the FHS and other LSB stuff.

> To be honest what I mostly seem to understand from your contributions
> to this bug a general but rather unfocused hostility to multiarch.  It
> is of course fine for you not to like multiarch.  But the purpose of
> the BTS is not to be an outlet for gripes; if it were I have plenty of
> my own.  The purpose of the BTS is for us to track specific problems,
> the correction of which lies in our power.

He said to the person advocating multiarch for the last 6 years.

Clearly I'm not the person to convince others to add multiarch tupples
to their specs. So someone with decent debating skills please pick up
this issue and get in contact with the FHS/LSB people.

> But I'm wasting too much of everyone's time arguing about the state of
> this now-non-bug.  It would be better just to let it sit and rot in
> the BTS so this will be my last message here.
>
> Ian.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#664257; Package debian-policy. (Fri, 27 Apr 2012 08:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 27 Apr 2012 08:33:04 GMT) Full text and rfc822 format available.

Message #131 received at 664257@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 664257@bugs.debian.org
Subject: Re: multiarch tuples are not documented/defined
Date: Fri, 27 Apr 2012 03:29:37 -0500
Goswin von Brederlow wrote:

> Clearly I'm not the person to convince others to add multiarch tupples
> to their specs.

I don't see why or why not.  But it isn't really about convincing ---
I'd be hard pressed to find someone who _doesn't_ want this stuff
documented better.




Severity set to 'normal' from 'important' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Sun, 12 Aug 2012 18:30:05 GMT) Full text and rfc822 format available.

Changed Bug title to 'document Architecture name definitions' from 'multiarch tuples are not in the FHS' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Sun, 12 Aug 2012 18:30:05 GMT) Full text and rfc822 format available.

Bug 664257 cloned as bug 684672 Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Sun, 12 Aug 2012 18:30:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#664257; Package debian-policy. (Sun, 23 Mar 2014 16:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 23 Mar 2014 16:33:05 GMT) Full text and rfc822 format available.

Message #142 received at 664257@bugs.debian.org (full text, mbox):

From: Bill Allombert <ballombe@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 664257@bugs.debian.org
Cc: 664257-submitter@bugs.debian.org
Subject: Re: Bug#664257: multiarch tuples are not documented/defined
Date: Sun, 23 Mar 2014 17:31:13 +0100
On Fri, Apr 27, 2012 at 01:41:01AM -0500, Jonathan Nieder wrote:
> Hi Russ et al,

First, thanks Jonathan a lot for providing this patch. While this is 
not the full story this gives us a better basis to document multiarch.
 
>  - what should the normative content be?  It would not be too strange
>    to put a firmware file that happens to be a MIPS binary in an
>    "Architecture: i386" or "Architecture: all" package, and I think
>    it is important to keep permitting that.
> 
>    How should this be worded to permit that sort of thing while still
>    making it clear that a package installing MIPS DSOs as NSS plugins
>    under /usr/lib/nss ought to use architecture: mips or mipsel?

Another similar case are binaries optimised for a sub architecture.
(e.g. SSE2 optimised libraries).

>  - what happens if an ABI document is just wrong?  (For example, I
>    have no idea whether the m68k psABI is accurate.)

For most practical purpose, the exact ABI is decided by the C compiler.
Thus we can expect gcc/clang upstream to deal with that.

>  - is it okay to rely so heavily on external resources?  Is it safe to
>    assume that the reader can look up link targets when needed, or
>    does link text need to be unambiguous?  Would we need to include a
>    summary or copy of some of the cited standards in case they
>    disappear?

Again, for most practical purpose, what matter is to be able to match the compiler
documentation with Debian documentation. If the compiler documentations states
that ABI=foo target "LSB IA64 4.1" and the Debian document says to target
"LSB IA64 4.1", then the developer know this is the right option without having
to read the ABI document.

> Improvements welcome, of course.  What do you think?

I am very tempted to merge your patch except for the first paragraph:

> +	<p>
> +	  Every Debian binary package must have an <tt>Architecture</tt>
> +	  control field which describes the ABI used by dynamically-linked
> +	  binaries and public shared libraries in the package and
> +	  packages it interacts with.  For example, packages built to run
> +	  on a 32-bit Intel-architecture GNU/Linux system would use an
> +	  <tt>Architecture</tt> of <tt>i386</tt>.
> +	</p>
> +
> +	<p>
> +	  Unless otherwise specified, dependencies specified using the
> +	  <tt>Suggests</tt>, <tt>Depends</tt>, <tt>Recommends</tt>, and
> +	  <tt>Pre-Depends</tt> fields refer to packages of the same
> +	  architecture.
> +	</p>
> +      </sect>

Some words about architecture-independent packages are in order.

But outside that, is there objections to merging this patch ?
Seconds ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Message sent on to Matthias Klose <doko@debian.org>:
Bug#664257. (Sun, 23 Mar 2014 16:33:12 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 08:18:50 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.