Re: Adding loong architecture to dpkg

[Zhang Ning <zhangn1985@outlook.com>]

On Wed, Nov 02, 2022 at 11:04:21AM +0100, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2022-11-01 at 19:45:11 +0800, 桑猛 wrote:
> > > We hope that the arch name can use loongarch64, mainly based on the
> > > following considerations:
> > > 1. The current upstream compilers gcc, llvm, etc. use loongarch64.
> 
> That's part of the GNU triplet name, which is related but has never
> needed to match the dpkg architecture.
> 
> > > 2. The current upstream kernel uses loongarch64.
> 
> Same here.
> 
> > > 3. At present, there is no special convention for the length of the
> > architecture name. If loong64 is used, it is easier to be confused
> > with the previously used loongarch64.
> 
> Well, length might be one aspect of this, as it ends up in filenames,
> and metadata, etc, but the «arch» part is just redundant and wasteful
> and gives no meaningful information. We had a similar situation with
> aarch64 which was a terrible name, which we named as arm64 for the
> dpkg architecture.
> 
> > The following code in https://man7.org/linux/man-pages/man1/dpkg-architecture.1.html:
> > 
> >  DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> >            DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
> >            […]
> >            ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
> >              confflags += --build=$(DEB_HOST_GNU_TYPE)
> >            else
> >              confflags += --build=$(DEB_BUILD_GNU_TYPE) \
> >                           --host=$(DEB_HOST_GNU_TYPE)
> >            endif
> >            […]
> >            ./configure $(confflags)
> > 
> > If you use loong64, it will be contrary to the loongarch64 logo used by
> > gcc, so we still want to use loongarch64 as the arch name。
> 
> This is not a very compelling argument TBH, many dpkg architectures,
> more so the ones most used, have GNU triplet CPU names not matching at
> all the dpkg architecture: aarch64 → arm64, x86_64 → amd64. We also
> have stuff like powerpc64le → ppc64el (which changes both CPU name and
> endianness annotation).
> 
> Given that any such architecture will have to be bootstrapped from
> zero for Debian, reusing an existing name is also not a very
> compelling argument. If in addition, as Zhang Ning mentions, those
> pre-existing architectures are also not even binary compatible, then
> that's even a stronger argument against even considering reusing it at
> all.

imcompatible is the major reason which makes me to select a different dpkg
name.

> 
> In any case, the loong64 name has already been used by other
> distributions (Gentoo, ArchLinux, Slackware, etc.), so this is really
> not unusual.

I was misleaded by Gentoo Loongarch maintainer, he told me it is
loong64, but actually, it's loong.
Archlinux and Slackware are downstream ports, not upstreamed yet.

My question is, is it necessary to use same name for all distos?
if true, the only choise is loong. I can accept it.

When Loongson releases 32bit loongarch, then loong32 can be its dpkg name,
if we select loong for 64bit. first come takes the shorter one.

BR.
Ning.

> Thanks,
> Guillem