Re: subarch support
On Fri, Jul 16, 2010, Riku Voipio wrote:
> On ARM one could have armelv5, armelv6, armelv7, armelv7neon
Hmm ok, I kind of prefer the Features/Capabilities idea: encoding that
this is an armel package which requires this or that feature at
runtime, exposing that in APT, and patching APT to prefer the other
deb. Perhaps some scoring mechanism to select this or that package.
Perhaps the two ideas are not incompatible, but I don't like using a
name as a proxy for features; that is, rather than saying we create a
armelv7neon subarch and everything builds for armelv7neon defaults to
armv7 + NEON, and systems which have armv7 and NEON should prefer it,
I'd prefer we'd say we create an armelv7neon archive, that has a
different default gcc or different default compile flags, and resulting
binary .debs are flagged as "requires: armv7, neon", then these are put
into an APT repo which has "requires: armv7, neon" as well, and
APT/dpkg on end-user systems select the best archive/.deb from a list
using some scoring.
Basically, I'd like to avoid the packages to use subarch tests and
subarch names and I'd like us to avoid maintaining a list of blessed
subarches.
What do you think?
> but ideally
> supported cpu features would be identified ./configure -time from what gcc
> accepts with given defaults.
Right; it's also acceptable to detect them in rules, by running gcc.
It might be a bit heavy to have one gcc per subarch, so we could ride
on the dpkg-buildflags wave to implement the default subarch CFLAGS and
such. This seems a bit futuristic still, so perhaps subarch could have
a wrapper for the compiler, like hardening-wrapper.
There's the question of where in the pool to put these packages, do we
actually include something like a subarch name in the package filename?
e.g. _armel+armv7neon.deb? Or do we change the recommended structure
for the pool?
Do we maintain multiple APT lists, or do we list all packages in a
single Packages.gz for armel, with the subarch specific packages
flagged as "requires: neon, armel"?
> This way ubuntu wouldn't have just had to drop armv5 support when
> building armv6 stuff, or make it impossible for lpia users to install
> i386 .debs.
Well... I agree with the lpia case now, but I don't think Ubuntu would
have maintained essentially two sets of binaries (in the worst case, 2
x buildds, 2 x archive space for *_armel.deb, 2 x validation of .debs
and images, 2 x debian-cd builds and space...). (Both because of
manpower and lack of ARM hardware and financial cost to host.)
(Again, note that the lpia ISA was meant to diverge, something which
never happened.)
Subarch in Ubuntu might have made sense for a whitelist of packages
though, that's true. Would have been harder to implement than libc-vfp
and pango-vfp passes and such, but it would have been more scalable to
e.g. tens of packages, I agree.
--
Loïc Minier
Reply to: