XPost: linux.debian.maint.dpkg

Hi,

I plan to implement freestanding architecture specification.
Following Toulouse debian mini debconf and javascript presentation it will be really helpful as a first step

https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches

First likley to be implemented will be UEFI arch.

Any pointer for dpkg code to modify/test will be helpful.

for adding uefi triplet (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F)
- UEFI was added to config
- binutils status and gcc is for me unknown. Help welcome here (dokko, skitt ?)

rouca
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmdDFqwACgkQADoaLapB CF8fAQ/+M5UcKglHAsVGhQ3y9WlpanvFxjsDowMUvyNpvYCs8y5Q2dWaoQNXQ7JM IEuqymUJO1cyMrzs0FFGElBG7Rx+f1D3x5bpPlsdLRQV6+s+uxf/oXWIIzj3lgbE 6NakMq10JEtzMYuHf+hDASV3117B7rFuKZE84OyV8z1bzn0/rOtC7I9/fMcWZzB2 qlZHmlKOvk1W+D0p/kW1JQHTNS69GVuj8uB/ikAtlE6FpAsdIhFkb7VMQZtMwp3s Ad+R4YO0EgSF16CjMoqtx+dY8OS74jeKOWOaUz7sRsPTIFpQY4stwDexuDEgD16n NWY/61b81mT38fLlTD1XqLJIolZ2vUS+J5BW12J3AcEB8aBZ53GM7RaXWQVkvDyD dG3K2/Hag/egwfvVitqIDEbglWDanD66N0C8PXuM+hw816oTiIyL9Y1GuvGH2eqU 2ITtQ5/xeVSAICHY+VHb1k/WBQspxbwnc/1kcGj82cirdWxr35mddxA9pWnMaGRo z5nOtKX0M5u4iDlOWzVtTpttd0cwZf89FrfgHMl05R/eVwdad2U7/2wIk2c6JWiH h4I2PswzxiPEhK9gRmnQaiIh8t6f8qg/VwHAEDsckyts8GE7rc5lNUHPL52XqlNi 7NwGpXxDTYM+TS1gRacWimHbKu8LQiiUa0kA5Y8f/fY8A/nTu8A=
=1+TM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.dpkg

This is a multi-part message in MIME format.

--nextPart3011671.9qvbl9jjF7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit :
Hi

This the patch I plan to debian arch

Could you cross check then I will add arch to config.guess

Hi,

I plan to implement freestanding architecture specification.
Following Toulouse debian mini debconf and javascript presentation it will be really helpful as a first step

https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches

First likley to be implemented will be UEFI arch.

Any pointer for dpkg code to modify/test will be helpful.

for adding uefi triplet (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F)
- UEFI was added to config
- binutils status and gcc is for me unknown. Help welcome here (dokko, skitt ?)

rouca

--nextPart3011671.9qvbl9jjF7
Content-Disposition: attachment;
filename="0001-Add-data-for-freestanding-arches.patch" Content-Transfer-Encoding: 7Bit
Content-Type: text/x-patch; charset="x-UTF_8J";
name="0001-Add-data-for-freestanding-arches.patch"

From 6387d92bc55eabd4674c968be49885be73dbfa33 Mon Sep 17 00:00:00 2001

From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= <rouca@debian.org>
Date: Sun, 24 Nov 2024 16:06:41 +0000
Subject: [PATCH] Add data for freestanding arches

---
data/ostable | 7 +++++++
data/tupletable | 13 +++++++++++++
2 files changed, 20 insertions(+)

diff --git a/data/ostable b/data/ostable
index 64f424490..260366088 100644
--- a/data/ostable
+++ b/data/ostable
@@ -21,12 +21,19 @@ base-uclibc-linux linux-uclibc linux[^-]*-uclibc
eabihf-musl-linux linux-musleabihf linux[^-]*-musleabihf
base-musl-linux linux-musl linux[^-]*-musl
eabihf-gnu-linux linux-gnueabihf linux[^-]*-gnueabihf +eabihf-unknown-none unknown-none-gnueabihf unknown-none-gnueabihf
eabi-gnu-linux linux-gnueabi linux[^-]*-gnueabi +eabi-unknown-none unknown-none-eabi unknown-none-eabi
abin32-gnu-linux linux-gnuabin32 linux[^-]*-gnuabin32 +abin32-unknown-none unknown-none-abin32 unknown-none-gnuabin32
abi64-gnu-linux linux-gnuabi64 linux[^-]*-gnuabi64 +abi64-unknown-none unknown-none-abi64 unknown-none-abi64
spe-gnu-linux linux-gnuspe linux[^-]*-gnuspe +spe-unknown-none unknown-none-gnuspe unknown-none-gnuspe
x32-gnu-linux linux-gnux32 linux[^-]*-g

XPost: linux.debian.maint.dpkg

Hi!

On Sun, 2024-11-24 at 16:09:42 +0000, Bastien Roucariès wrote:

Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit :

I plan to implement freestanding architecture specification.
Following Toulouse debian mini debconf and javascript presentation it will be really helpful as a first step

https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches

First likley to be implemented will be UEFI arch.

Any pointer for dpkg code to modify/test will be helpful.

I've had the following branch for a while:

<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/arch-none>

The main problem is that the «none» part involves both a bit weird or unexpected semantics, and to add support for it, would imply modifying
not only all currently known code handling build dependencies and
architecture fields from debian/control, but also the magic run-time
matching from the base arches to their «none» compatible counterparts
(with implicit arch tuples; and thus expose their internal representation
to layers that have not had to care at all about this).

The weird/unexpected semantics are related to the fact that «any» will currently match «none», so this cannot even be used right now, as you'd
get a full arch with the none-arch buildds trying to build pretty much
the whole distribution, and not being able to discern what is
specifically relevant. Then, if we managed to change every arch
comparators, there's the problem that then «any» no longer would match
_any_ arch value, which seems strange to me. I mean we have the «all»
arch which is similar in the sense that «any» does not match it, so I
guess it could be thought in similar terms. Or there could be the
alternative though, to extend our handling of «all» to make it more
fine grained, so we could have:

all-amd64
linux-all
musl-all-all

(AFAIR this has been brought up in the past, but I don't have references
at hand and I cannot recall who proposed this first, whether it was me,
perhaps Paul Wise, or someone else?)

This might perhaps(?) be less confusing than using «none», and
certainly more generic and probably more useful for more things, but it
would still imply several of the problems mentioned above.

In the end, while something like this could be implemented, as I
mentioned last time you asked, IMO this needs to be discussed first with
the various infrastructure teams, and whether they could see something
like this being supported (say in the archive adding the partial repos
for these arches, in d-i by adding these as part of the installation,
as part of the release process to handle potential cross arch
dependencies, etc), otherwise, while I think in an ideal world it might
be nice to have support for it, it would be kind of a wasted effort.
And in general terms we should also be thinking what are the actual
benefits, compared to the amount of work and infrastructure and
documentation changes that this might imply.

I think adding this to the GNU config project might have similar
consequences with how GNU triplets might get matched and normalized?
And AFAIR, GNU config does not even have a concept of something like
«none» or «all».

for adding uefi triplet (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F)
- UEFI was added to config
- binutils status and gcc is for me unknown. Help welcome here (dokko, skitt ?)

I think it depends how this would look like, but in general I think if
we consider UEFI as a sort of an OS with a specified ABI, then this
seems less of a «none»/generalized-«all» arch, and adding it would have similar problems with how to decide not to build for such UEFI buildd.

This the patch I plan to debian arch

Adding the definitions has never really been the problem. The problem
is finding semantics that make sense and do not have weird/unexpected
behavior, and I guess ideally that do not require modifying the entire
build dependency parsing code around nor architecture handling in all
the relevant projects (but perhaps this last point is not possible to
avoid).

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.dpkg

Le mardi 26 novembre 2024, 00:29:40 UTC Guillem Jover a écrit :

Hi!

On Sun, 2024-11-24 at 16:09:42 +0000, Bastien Roucariès wrote:

Le dimanche 24 novembre 2024, 12:06:26 UTC Bastien Roucariès a écrit :

I plan to implement freestanding architecture specification.
Following Toulouse debian mini debconf and javascript presentation it will be really helpful as a first step

https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches

First likley to be implemented will be UEFI arch.

Any pointer for dpkg code to modify/test will be helpful.

I've had the following branch for a while:

<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/arch-none>

The main problem is that the «none» part involves both a bit weird or unexpected semantics, and to add support for it, would imply modifying
not only all currently known code handling build dependencies and architecture fields from debian/control, but also the magic run-time
matching from the base arches to their «none» compatible counterparts
(with implicit arch tuples; and thus expose their internal representation
to layers that have not had to care at all about this).

The weird/unexpected semantics are related to the fact that «any» will currently match «none», so this cannot even be used right now, as you'd
get a full arch with the none-arch buildds trying to build pretty much
the whole distribution, and not being able to discern what is
specifically relevant. Then, if we managed to change every arch
comparators, there's the problem that then «any» no longer would match _any_ arch value, which seems strange to me. I mean we have the «all»
arch which is similar in the sense that «any» does not match it, so I
guess it could be thought in similar terms.

Or there could be the
alternative though, to extend our handling of «all» to make it more
fine grained, so we could have:

all-amd64
linux-all
musl-all-all

(AFAIR this has been brought up in the past, but I don't have references
at hand and I cannot recall who proposed this first, whether it was me, perhaps Paul Wise, or someone else?)

I think here debusine will help.

None will be a special case of all

This might perhaps(?) be less confusing than using «none», and
certainly more generic and probably more useful for more things, but it
would still imply several of the problems mentioned above.

In the end, while something like this could be implemented, as I
mentioned last time you asked, IMO this needs to be discussed first with
the various infrastructure teams, and whether they could see something
like this being supported (say in the archive adding the partial repos
for these arches, in d-i by adding these as part of the installation,
as part of the release process to handle potential cross arch
dependencies, etc), otherwise, while I think in an ideal world it might
be nice to have support for it, it would be kind of a wasted effort.
And in general terms we should also be thinking what are the actual
benefits, compared to the amount of work and infrastructure and
documentation changes that this might imply.

Yes it is a chicken and egg problem.

Debusine team might help but it need dpkg support,so we must begin by something

I think adding this to the GNU config project might have similar
consequences with how GNU triplets might get matched and normalized?

Last config was adding none with wit arch and ABI so
x86_64-unknown-none-elf was a perfect archit triplet

And AFAIR, GNU config does not even have a concept of something like
«none» or «all».

for adding uefi triplet (https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F)
- UEFI was added to config
- binutils status and gcc is for me unknown. Help welcome here (dokko, skitt ?)

I think it depends how this would look like, but in general I think if
we consider UEFI as a sort of an OS with a specified ABI, then this
seems less of a «none»/generalized-«all» arch, and adding it would have similar problems with how to decide not to build for such UEFI buildd.

Yes but the freestanding arch is a first step toward cross build partial arch

This the patch I plan to debian arch

Adding the definitions has never really been the problem. The problem
is finding semantics that make sense and do not have weird/unexpected behavior, and I guess ideally that do not require modifying the entire
build dependency parsing code around nor architecture handling in all
the relevant projects (but perhaps this last point is not possible to
avoid).

Thanks,
Guillem

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmdFnsIACgkQADoaLapB CF++UxAAojhOanjMmWhhoDHyWwwUY0VPlEvcsh/bZNjwLqJrJVYHtzOnfwsdONhn M/wICo7nbIQ6pK3mXLxPfVUbWLeCm02Bt/9g3kDWQVESlGkzWw2iEBqcip51iuG3 311dxxoty5QgXwFoAdqiALD2NFAdH+GCqdVyG8aydrje0F09/Yio4lZFE4NCppLP FtPbFDCflUIP7TU1L9PS7+IaX/lhScyHUeqbkNcN1IYm0c7cFO79zwzDehj3PpPI yffgnw+iQd68bDHlhyIlJgq7uzrgAbQMX57BEI4Xug7MP4vXxAYU0yyVGWCEI3tg TFNUw1HHvXWwZIEDT5iUEVn5yT1bGz7h18UrTNEkr1TT6gr+6EI8hCOY65FnDykY xJWJACNnWjW+s0sSIX/G4vQA+6XffDfwFP2UE1vhEh064+biGNpJJCHIKSfw60Yc siaHj9Fg3tb5jH0dtn4DlKHq/x24CkG12OTYvXqFGhzODiratdnkoKdTLphWwPao V8+U8rd80H3enblEEGufsKrg6yjiYguryCmXHKM0C+RxWNIZRwkByDnQaKp2RT90 FRbSA20A1csZAa056skcseMt3v6bdlLF2kaOC/aREpAfNbMU++hQTtEOvUaSKhao og//Xr9hNyGOTgo5RriHxQ7LtepAJrBUE1/1OD1pxnB0L4fTDLY=
=/Vot
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)