Re: [Fwd: Re: Bug#254598: Name of the Debian x86-64/AMD64 port]
(Note that this mail isn't CC'd to the bug report. I will send a note
there saying that the discussion will be / should be taken to the
debian-ctte list.)
I agree that it is the porting team's primary responsibility to choose
the name. I don't think that this is the dpkg maintainers' decision,
although the dpkg maintainers do have a role in (for example) defining
the permissible syntax.
I think that the TC do probably have the power to intervene because
the issue is definitely covered by at least some of the things
included explicitly in the list in s6.1(1) of the constitution
(`technical policy') and maybe also because of s6.1(2) (about the need
for compatibility).
But, the TC should base its decisions on technical criteria, and
intervene only in technical decisions. If there are no good or
relevant technical reasons to intervene then the TC should not
interfere with the decision of the maintainers primarily responsible.
It's not altogether clear that this is a technical decision, but we
should consider whether there are relevant technical arguments:
* `Compatibility' with other distributions, Linux kernel, GNU
triplet, LSB, RPM, etc.:
I think these are very weak as technical arguments. Our packaging
software doesn't directly use architecture names from other
contexts without an opportunity for translation.
So there is no need for us to pick exactly the same name as
everyone else. If everyone else were 100% consistent and had
picked a name which fitted into our syntax, then we should probably
follow it. But in this case there seems at least to be substantial
amounts of confusion or disagreement.
* User confusion:
Users, it seems, will already have to cope with two names for the
architecture. It is a shame that the chip companies' marketing
people have muddied the waters, but I think it's probably too late
to undo.
* One name or another is AMD's official name for the architecture:
This is a marketing question, not a technical question. Marketing
input should in general be ignored, as it serves to confuse as
often as to clarify.
* Underscores in architecture names not permitted by dpkg:
I think this is an excellent reason to forbid them, and it is fully
within the dpkg maintainers' remit to specify the permissible
syntax. dpkg should definitely not be changed for this purpose.
But, that doesn't allow us to rule out anything but what seems to
be an outside contender anyway.
* Hyphens used in eg `hurd-i386' to separate kernel and processor:
I don't know whether this is a general rule yet, but it seems
a little foolish to introduce a hyphenated name where a single atom
would suffice and where we might later choose to add semantics to
the hyphen (if we haven't done already).
This does seem like a technical question, but I think we need more
information.
* The port is complete with `amd64' and we don't want to change:
This isn't an overriding argument - if there were a good reason
to change, we might well do so despite the pain. But it does add
weight in favour of `amd64'.
Pretty much all of these lead me to conclude that we should resolve
along the following lines:
* In our opinion the porting team are the right people to be deciding
on the architecture name, in general.
* In our opinion there is no significant technical reason to
interfere with the porting team's decision; on the contrary, we
largely agree with the porting team's choice of `amd64'.
* In our opinion architecture names with underscores in should not be
used because of the existing use of underscore as a separator in
package filenames, etc.; accordingly we advise that these should be
avoided.
* Since names with hyphens in are currently only used when separating
variant kernel-processor combinations, we advise that this practice
should be continued.
* Therefore, insofar as we are granted any authority by the
constitution, we uphold the porting team's choice of `amd64'.
* We request that dpkg should be changed to use `amd64'.
Should the dpkg maintainers decline, we will seek clarification of
the Constitution and consider using our powers in 6.1(1), 6.1(2) or
6.1(4) to overrule the dpkg maintainers.
Jason Gunthorpe writes ("Bug#254598: Name of the Debian x86-64/AMD64 port"):
> It would be terribly nice to be able to use the LSB mandated x86_64 as the
> arch name - simply because it is LSB. I'm not sure of the implications of
> extra _'s in filenames though. AFAIK nothing should actually be parsing
> the filenames like this so it might be ok.
As you can tell from what I wrote above, I disagree strongly. The
set of permitted characters in a namespace should never be extended
for marketing reasons !
(And yes, I know that it is frequently done in what people laughably
call the `real world', so don't quote examples.)
Raul Miller writes ("Bug#254598: Name of the Debian x86-64/AMD64 port"):
> I don't see any reason why dpkg can't support both x86-64 and amd64.
> This would look slightly ugly when displaying known architectures but
> that's not a technical issue.
I think an alias for this is a bad idea. There's no real need and it
would just lead to confusion. You mention the archive, but there are
other places where lists of architectures appear. Every piece of
software would no longer be able to simply compare architecture names
with string comparision.
Thanks,
Ian.
Reply to: