Package problem

[David Cournapeau]

On Tue, May 19, 2009 at 9:29 PM, A. Cavallo <a.cavallo at cavallinux.eu> wrote:
>> > It is solved in other languages.. for example perl.. and delphi
>> I don't know much about perl, and even less about delphi, but I am
>> pretty sure it does not solve the problem of overwriting files from a
>> package with an installation outside the control of the package
>> manager.
>
> On a sytem a possible solution would be:
>
>  /usr/lib/python2.5/site-package/foobar <- The os managed one
>  /usr/lib/python2.5/site-package/foobar-2.0 <- The alternatives
>  /usr/lib/python2.5/site-package/foobar-2.1
>
> and using something (in the python interpreter)
>
> import foobar (imports the foobar)
> import foobar requires >= 2.1 (imports foobar 2.1 or above)

This does not solve the discussed problem. If you revwrite foobar-2.0
with foobar-2.0 installed from sources, you don't know whether you
will break the system. You will most likely do so, because of
difference filesystem conventions, for example. And what will happen
when you will do apt-get remove foobar-2.0 (on a .deb system) ? Most
likely, as the set of files installed from sources are not exactly the
same as the set of files installed by dpkg, the uninstall will be
broken. Specially in the case of configuration files, or daemon, this
may be quite serious.

>>
>> There is no simple solution to the following situation:
>>    - install setuptools from ubuntu -> files get into /usr
>> (/usr/lib/python2.5/site-packages, etc...)
>
> setuptools is the problem;) It tries to do too many things imho.

The discussion has nothing to do with setuptools, or even python for
that matter. The problem is that overwriting files managed by the
software management system without its consent is bound to be broken,
on any system (including windows). That's why you should avoid
installing from sources into the locations managed by the OS, be it
/usr for unix, or C:\Windows on windows, etc...

David