On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote: > Personally, before any further discussion I'd like to see some numbers > with core libraries (libc, libgcc, libgmp, libatlas? etc) built with > softfp, which eventually might be able to switch to use the hwcaps > infrastructure in a similar way as how packages like libc6-i686 are > handled.
The key limitation with hwcap approach is that it only extends to shared libraries. Optimized binaries and plugins cannot be provided with hwcaps. Things like libc-i686 are also problematic for endusers. How do I quickly install all 686 optimized versions of libraries I already have? > Adding a new (official) architecture variant is a huge overhead for > everyone, it implies adding new porter boxes, patching packages (but > hopefully not many) to handle the new arch, having someone handle the > build daemons, Adding a new arch creates a big overhead for *selected* people, rather than everyone - most packagers in debian are unaffected. Multiple libraries is not exactly zero-effort either, there could easily be hundreds libraries we could want optimized. That is if we want to provide a *good* service to users with VFP's rather than a lipservice. And we still wouldn't have a vfp version of quake2. > The lpia is a great example of an architecture variant that was a > mistake, and should haver never been created. LPIA was mainly a issue since people used it as "if arch=lpia then build mobile ui". That prevented users from installing full versions of software or trying mobile UI's in regular i386 installations. If dpkg had subarchitecture support, lpia wouldn't have been as big a issue. Ubuntu decided to shortcut and not add support for compatible subarchs in dpkg, and the result was what it always is when people make shortcuts... Subarchs could also be useful if we wanted to build softfp abi compatible armv6/armv7 armel builds of the whole debian repository. Of course we could do builds without subarchs, but then users would be unable distinguish which installed packages are for which cpu, and providing that via debian infra would not be possible. But the key difference with lpia and hardfloat armel is that they are not binary compatible. And if we use it as a opportunity to target armv7+, do not really share much of hardware either. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
