Package problem

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

On Tue, 19 May 2009 13:15:14 +0900, David Cournapeau <cournape at gmail.com>
wrote:
> On Tue, May 19, 2009 at 4:52 AM, Sverre <sverreodegard at gmail.com> wrote:
>> 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