pmatilai left a comment (rpm-software-management/rpm#2197)
Been thinking about this again, and wondering if we couldn't get away with an
optional "flags" field consisting of single letters in alphabetical order:
`<arch>-<bits>[-<flags>]` that's only there for exceptional stuff like
configurable endianness or varying floating point system, and which are
generally platform specific. So we wont try to encode general characteristics
of the platform into this arch classifier, only what's absolutely necessary to
differentiate. So you might have something like
b - big endian (and lack of it means little-endian, the common norm these days)
s - software FPU (and lack of it means hardware, as per the norm)
t - thumb for Arm Thumb instruction set
x - extended instruction set - for example x32 would then be x86-32-x
...and since they are arch-specific, you have 25 flags to choose from, double
that if you include uppercase and even more if numbers are allowed. Should be
enough space for even all the wacko Arm variants π There's no doubt *some* such
flags are technically generic in nature, like endianess. But whether it makes
sense to eg reserve lower-case for common and upper-case for arch-specific or
some such thing, I kinda doubt it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2197#issuecomment-2659382611
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2197/2659382...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
