Policy proposal: Cpu extension code, update-ldsoconf

[Camm Maguire <camm@enhanced.com>]

Greetings!  This is hardly formal, but it seems as though we don't
have a policy on this yet, and a number of packages are appearing
(e.g. atlas, gmp2) which can benefit enormously through the use of cpu
extension instructions, such as {SSE,3DNow{{1,2}.

Proposal outline:

1) All code which will not run on all machines of its general
   architecture should be separated into a shared library.

2) This library should be placed in a designated subdir of /usr/lib
   specialized for code requiring the cpu extension in question.  All
   such directories should be agreed on and sanctioned by the policy
   committee.  As a suggestion, the directory might be named after
   the cpu capability (as reported in /proc/cpuinfo) required to run
   the code, e.g. /usr/lib/xmm, /usr/lib/3dnowext, etc.)

3) All functionality provided by this code should also be provided by
   a binary-equivalent generic shared lib of the same name and soname
   in /usr/lib.

4) Ideally, ldso should be smart enough to search the special
   directories first given the running cpu characteristics.  Barring
   this, a system script, update-ldsoconf, should be created, which
   packages can call at install/remove time, to add/remove the
   specialized paths appropriate to the running cpu to /etc/ld.so.conf
   ahead of /usr/lib and then run ldconfig.  Optionally (and
   preferably), this script could also be run at boot time to catch
   cpu-upgrades and/or kernel upgrades (SSE requires kernel support).
   The path need not be added, and can be removed, if no libs exist in
   the directory.

Comments most welcome, but please cc me directly, as I'm not
subscribed to some of these lists.

Thanks for your work on Debian!

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah