Dear maintainer,

We need to split out qemu-system-loongarch64 from qemu-system-misc to
qemu-system-loongarch64 package.
Please consider the patch we have attached.
And the qemu 9.2.0+ds-3 source package was compiled successfully on my
local loong64 rootfs environment.
```
......
dpkg-deb: building package 'qemu-system-s390x' in
'../qemu-system-s390x_9.2.0+ds-3_loong64.deb'.
dpkg-deb: building package 'qemu-system-loongarch64' in
'../qemu-system-loongarch64_9.2.0+ds-3_loong64.deb'.
dpkg-deb: building package 'qemu-system-ppc' in
'../qemu-system-ppc_9.2.0+ds-3_loong64.deb'.
dpkg-deb: building package 'qemu-system-x86' in
'../qemu-system-x86_9.2.0+ds-3_loong64.deb'.
dpkg-deb: building package 'qemu-user' in
'../qemu-user_9.2.0+ds-3_loong64.deb'.
dpkg-deb: building package 'qemu-user-static' in
'../qemu-user-static_9.2.0+ds-3_loong64.deb'.
dpkg-deb: building package 'qemu-system-riscv' in
'../qemu-system-riscv_9.2.0+ds-3_loong64.deb'.
dpkg-deb: building package 'qemu-system-arm' in
'../qemu-system-arm_9.2.0+ds-3_loong64.deb'.
  dpkg-genbuildinfo --build=any -O../qemu_9.2.0+ds-3_loong64.buildinfo
  dpkg-genchanges --build=any -O../qemu_9.2.0+ds-3_loong64.changes

```
Would it be possible to include the attached patch in the next upload?
If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

24.12.2024 15:19, zhangdandan wrote:

First, I'd love to have "generic" names for the cpu *families* in package names.
Like we have for ppc (which is a family name including several different CPUs).
"loongarch64" does not look like a family to me, more like a specific architecture.
Maybe "loongarch" would be better, but I don't know if it can be confused with
the 32bit loongarch.

(yes I know we've s390x here, it was a (bad) historic precedent).

And second, for splitting things out of qemu-system-misc, I'd want the architecture(s)
in question to be in list of debian release architectures first, - ie, not as a "port"
architecture but as a regular fully supported architecture.  This is a clear criteria,
or else we've discussions what should be in -misc and what should be by its own.

If the reason you want this split is because you want to *install* something which will
*provide* the needed binary, - you can do it today, by installing qemu-system-loongarch64 -
it is currently provided by qemu-system-misc.  If you do this today, you wont need to
change your dependencies later, it wouldn't matter which package actually provides the
needed functionality, and it will continue to work even if we'll merge all qemu-system
subpackages into one qemu-system.

So the real question is: *why* do you need to split qemu-system-loongarch64 out?

Thanks,

/mjt

Dear mjt,

On Tue, 24 Dec 2024 15:29:15 +0300 Michael Tokarev wrote:

 > Control: tag -1 moreinfo
 > Control: severity -1 wishlist
 >
 > 24.12.2024 15:19, zhangdandan wrote:
 > > Dear maintainer,
 > >
 > > We need to split out qemu-system-loongarch64 from qemu-system-misc
to qemu-system-loongarch64 package.
 >
 > 2 points.
 >
 > First, I'd love to have "generic" names for the cpu *families* in
package names.
 > Like we have for ppc (which is a family name including several
different CPUs).
 > "loongarch64" does not look like a family to me, more like a specific
architecture.
 > Maybe "loongarch" would be better, but I don't know if it can be
confused with
 > the 32bit loongarch.
 >
 > (yes I know we've s390x here, it was a (bad) historic precedent).

We agree with what you said.
I checked the definition of system-archlist-*(x86/arm/ppc/riscv/sparc)
in debian/control.mk.
Maybe "qemu-system-loongarch" would be better named as a software package.

 > And second, for splitting things out of qemu-system-misc, I'd want
the architecture(s)
 > in question to be in list of debian release architectures first, -
ie, not as a "port"
 > architecture but as a regular fully supported architecture. This is a
clear criteria,
 > or else we've discussions what should be in -misc and what should be
by its own.

If you think it is time to separate loongarch64 from misc, please remind
me, thanks.
we will update the patch in time.

 > If the reason you want this split is because you want to *install*
something which will
 > *provide* the needed binary, - you can do it today, by installing
qemu-system-loongarch64 -
 > it is currently provided by qemu-system-misc. If you do this today,
you wont need to
 > change your dependencies later, it wouldn't matter which package
actually provides the
 > needed functionality, and it will continue to work even if we'll
merge all qemu-system
 > subpackages into one qemu-system.

As you said, we can do it today, by installing qemu-system-loongarch64
-it is currently provided by qemu-system-misc.
The current status is: we add qemu-system-misc in other packages which
depend qemu-system-loongarch64 binary, e.g. libguestfs.

 > So the real question is: *why* do you need to split
qemu-system-loongarch64 out?

Referring to other architectures supported by Debian QEMU, we think that
split qemu-system-loongarch64 out from misc is more in line with the
specifications of Debian QEMU.
At the same time, install qemu-system-loongarch{64} software package to
obtain qemu-system-loongarch64 binary, which is more in line with the
user's usage habits.
Your opinions are welcome.

Best regards,
Dandan Zhang

07.01.2025 05:48, zhangdandan wrote:
...

Please don't.  Please depend on qemu-system-loongarch64 instead of qemu-system-misc.
This works now, and this will work with any future split, and you wont need to change
anything in the future.  Also, please depend on particular architecture you're interested
in, not the qemu package name, because there's a chance we'll split things further.

qemu-system-loongarch64 provides this particular architecture emulation, this is what
you need and this is what you should depend on.

I wonder how the current dependencies in guestfs looks like..
one of the "misc" things.  And it's somewhat depressing to be in the "misc" category.
For me, the line is simple: every architecture which is a release architecture in
debian, deserves the thing to be in its own package.

There are two more things to consider.  For me, I should remove qemu-system-sparc
package and stuff it into qemu-system-misc now, since sparc is not a debian release
architecture *anymore* (but it was in the past).  And for everyone else, - qemu is
moving towards single binary emulating ALL architectures.  So the whole split will
become a moot point entirely, as there will be just a single qemu-system package,
providing everything which all various qemu-system-foo packages providing now.
package to obtain qemu-system-loongarch64 binary.  The fact that this package is
currently virtual does not really change anything, - the user needs to install
just the qemu architecture they are interested in.

Please depend on qemu-system-loongarch64 (of particular version if you need to),
and everything should be fine.

Thanks,

/mjt