[Distutils] Fixing parallel installs with easy_install / setuptools

[Garrett Cooper]

Hello distutils folks,
    My group at Cisco uses easy_install / setuptools extensively for
installing packages with our make system and there are 2 issues with
using this with parallel make:
    1. Duplicate dependencies cause corruption when installing the
same package twice.
    2. easy-install.pth is never updated according to the installed
packages. Thus when we install 8+ packages and they all depend on
python being installed
    3. Cross-compilation is impossible (at least with what I've seen
-- either that or the folks who hacked the sources before I got to it
didn't understand that feeding in the correct variables would ensure
that things could cross-compile). Then again many things Python don't
cross-compile from what I've seen :(... the interpreter itself is a
prime example =\.
    My goal is to fix these issues and contribute back the fixes, but
I want to ensure that I use the best technical solution for the
problems I mentioned.
    About problems 1 + 2:
        I'm short on time so I'm going to implement a simple locking
mechanism around easy-install.pth. I also realize that .pth files are
chosen because they are flat files and are included simply from within
python with setup.py. Would it make more sense to use a backend
database like pysqlite to store the package data though? That would
require some reworking with setup.py, but considering that sqlite3 is
_already_ included with 2.5+ and it's a public domain licensed piece
of OSS software, would it make more sense to store packaging data with
a stable system like SQLite, especially when it would make removal a
trivial task? My knowledge of SQLite is limited, but I assume that it
supports the same level of endian neutral code that other technologies
like BDB do. Of course I'm going out on a huge limb in making that
assumption, but the only document I found that blatantly disproves my
claim straight out is
http://groups.google.com/group/wview/browse_thread/thread/6fcc993dd548206c/fef9608843533ef7?#fef9608843533ef7
-- please correct me if I'm totally off-base.
    Also, please let me know whether or not you disagree with my
proposal, and if there's a different method that could be employed
which could maximize data integrity, assure ATOMicity, and guarantee
that the data is endian neutral and thus portable to multiple
platforms.
    About problem 3:
        Is the solution simple enough to solve using --build, --host,
and/or --target, like configure, or does more gross work need to be
done under the covers to make things all work?
Thanks!
-Garrett