[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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: