Package problem

[Sverre]

I'm using Ubuntu and some of the packages in the repository are too
old. So I got the thought to remove nearly all packages downloaded
from the repository and install them with easy_install. Is this a way
to go without greater problems?

 

[A. Cavallo]

I'm using Ubuntu and some of the packages in the repository are too
old. So I got the thought to remove nearly all packages downloaded
from the repository and install them with easy_install. Is this a way
to go without greater problems?

If you're installing as root probably this will cause a dependency nightmare.

Installing any file in the filesystem without using a package manager
(deb/rpm) will garantee these files will be overwritten on the next
update/upgrade (it can be triggered also by another package).

Regards,
Antonio

 

[David Cournapeau]

I'm using Ubuntu and some of the packages in the repository are too
old. So I got the thought to remove nearly  all packages downloaded
from the repository and install them with easy_install. Is this a way
to go without greater problems?

This is probably the worst way to do it

As a rule, you should never install anything from sources (be it
python packages or anything else) in /usr, which should be considered
as 'owned' by the package. By /usr is owned, I mean that anything
installed with prefix /usr (/usr/lib, /usr/include, etc...) can be
overwritten by the Ubuntu package manager. Unfortunately, by default,
python setup.py install will install in /usr (whereas most sources
packages installed in /usr/local/ if no --prefix is given - that's the
case of any software using autoconf, like python for example).

You could either install system-wide (for all users) in /usr/local, or
somewhere just for yourself. To handle dependencies, you could use
something like virtualenv for packages using autotools. For
development, a more heavy-weight (but more reliable) method is to use
chroot and other 'jail-like' systems.

You should avoid building by yourself things which depend on a lot of
C libraries - it quickly becomes unmanageable in my own experience.
For some distributions which have long release periods (e.g. RHEL),
that's a significant problem without any easy solution (I almost
always use a virtual machine in that case if possible).

cheers,

David

 

[David Cournapeau]

something like virtualenv for packages using autotools.

^^^^^^^
Sorry, I meant setuptools here, not autotools

David

 

[David Lyon]

Hi David,

I guess paraphrased you are saying "don't touch your packages"..

To my point of view, the needs of the developer override the
priorities of the O/S house...

We should expect "old" packages on our systems from the O/S

and have an easier way to update them to whatever we want..

That's why imho, we can benefit with a package manager tool
that can do just that. I just don't have anything running
on ubuntu just yet - sadly.

 

[David Cournapeau]

Hi David,

I guess paraphrased you are saying "don't touch your packages"..

To my point of view, the needs of the developer override the
priorities of the O/S house...

We should expect "old" packages on our systems from the O/S

and have an easier way to update them to whatever we want..

That's why imho, we can benefit with a package manager tool
that can do just that. I just don't have anything running
on ubuntu just yet - sadly.

Given that nobody has managed to solve this problem, I doubt you will
find a solution. If there was a reasonable solution, it would have
already been developed. Solutions for developers include independent
environments, avoiding dependencies as much as possible, and
controlling everything by yourself. Trying to fight the OS deployment
system is thinking backward IMHO.

cheers,

David

 

[David Lyon]

Given that nobody has managed to solve this problem, I doubt you will
find a solution.

It is solved in other languages.. for example perl.. and delphi

If there was a reasonable solution, it would have
already been developed.

Maybe we are slower because we like to do things "better"

Trying to fight the OS deployment system is thinking backward IMHO.

Fight it ??? I didn't even get a python interpreter with my operating
system...

So there's no possible way I can be against it...


David

 

[A. Cavallo]

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)

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.

You could try:

http://download.opensuse.org/repositories/home:/cavallo71:/python-opt/

This is a python interpreter installed under /opt/opt-python-2.7a0.
All you have to do is sourcing /opt/opt-python-2.7a0/opt-python-env.sh
from a shell and start using the python 2.7 (it's directly from the svn
trunk).

If you download a python module to generate the rpm for it all you have to do
is:
$> . /opt/opt-python-2.7a0/opt-python-env.sh
$> python setup.py bdist_rpm

It will generate a package rpm installable under /opt/python-2.7a0 and won't
interfere with the system.

I hope this will help,
Regards,
Antonio

 

[David Cournapeau]

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.

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

 

[David Lyon]

The discussion has nothing to do with setuptools, or even python for
that matter.

It has everything to do with python....

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...

I actually kind of agree with what you're saying here. Under Linux
it seems to me that users shouldn't be playing around in the
bowels of /usr/.... or anything lower...

but....

site-packages is the directory that one would want to keep
python packages in. That should be a developer/sysop area
and not owned and run by the o/s.

maybe... maybe... although too late now (?) somewhere
like /etc/site-packages might be a lot better place to
keep ones site packages. Or /opt.

Under windows in python 2.6, they have this concept of
user-packages.

One could easily also apply that concept to linux and
have a /home/user/.user-packages directory in which
one could keep all ones user packages.

The problem is that overwriting files managed by the
software management system without its consent is bound to be broken,

Something like what I describe above would totally
satisfy linux system organisation requirements.

David

 

[David Lyon]

You could try:

http://download.opensuse.org/repositories/home:/cavallo71:/python-opt/

This is a python interpreter installed under /opt/opt-python-2.7a0.
All you have to do is sourcing /opt/opt-python-2.7a0/opt-python-env.sh
from a shell and start using the python 2.7 (it's directly from the svn
trunk).

If you download a python module to generate the rpm for it all you have to
do
is:
$> . /opt/opt-python-2.7a0/opt-python-env.sh
$> python setup.py bdist_rpm

It will generate a package rpm installable under /opt/python-2.7a0 and
won't
interfere with the system.

I'm fascinated by this and want to try...

The above just gave me an ftp link?

Can you explain again how to do it?