[Distutils] Setuptools' goal in rpm/deb-based systems

[Jeff Pitman]

Hi,

This may have been discussed ad nauseum already, but as I tried to
package turbogears for Fedora/CentOS, I thought I'd throw in 2 cents.

From a .deb and .rpm perspective, it is highly discouraged to install
non-system managed files into non-$HOME areas (esp. /usr). Even for
many, /usr/local is highly frowned upon (eg. ./configure; make; make
install mantra).

I see that --single-version-externally-managed has been added as an
option so that .deb/.rpm packaging can take advantage of that relying
upon apt/yum/smart to take care of business. Hopefully, this will be
pushed out soon. (Because turbogears script generation is not trivial
to package. I think I'll just include a generated script as one of the
Sources, for now.)

I think the goal for setuptools on rpm/deb-based systems should focus
on getting $HOME setup and managed correctly for packages not provided
by the system. For example, if I had an ISP which provided python2.4,
but not TurboGears, then I could use .egg to manage a setup in $HOME
to use the packages correctly. Currently, -d/-s and other options can
be used. But, if the user isn't root, maybe it should be the default
behavior: install and manage in $HOME.

Also, are there efforts to detect if a package is already installed?
For example, if "python-sqlobject" is installed, can setuptools detect
the lib if the install_requires has "SQLObject"? I think peering
between .egg and .deb/.rpm to be a difficult problem. So, having it
all or nothing would be a cleaner policy. .deb/.rpm to manage /usr
installed packages/modules and .egg to manage $HOME installed
packages.

Thoughts?

--
-jeff