Package problem

Discussion in 'Python' started by Sverre, May 18, 2009.

  1. Sverre

    Sverre Guest

    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?
     
    Sverre, May 18, 2009
    #1
    1. Advertising

  2. Sverre

    A. Cavallo Guest

    On Monday 18 May 2009 20:52:52 Sverre 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?


    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
     
    A. Cavallo, May 18, 2009
    #2
    1. Advertising

  3. On Tue, May 19, 2009 at 4:52 AM, Sverre <> 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
     
    David Cournapeau, May 19, 2009
    #3
  4. On Tue, May 19, 2009 at 1:15 PM, David Cournapeau <> wrote:

    > something like virtualenv for packages using autotools.


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

    David
     
    David Cournapeau, May 19, 2009
    #4
  5. Sverre

    David Lyon Guest

    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 <>
    wrote:
    > On Tue, May 19, 2009 at 4:52 AM, Sverre <> 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
     
    David Lyon, May 19, 2009
    #5
  6. On Tue, May 19, 2009 at 1:31 PM, David Lyon <> wrote:
    >
    > 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 Cournapeau, May 19, 2009
    #6
  7. Sverre

    David Lyon Guest

    On Tue, 19 May 2009 13:53:18 +0900, David Cournapeau <>
    wrote:
    > 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
     
    David Lyon, May 19, 2009
    #7
  8. Sverre

    A. Cavallo Guest

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

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


    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
     
    A. Cavallo, May 19, 2009
    #8
  9. On Tue, May 19, 2009 at 9:29 PM, A. Cavallo <> 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
     
    David Cournapeau, May 19, 2009
    #9
  10. Sverre

    David Lyon Guest

    On Wed, 20 May 2009 00:40:28 +0900, David Cournapeau <>
    wrote:

    > 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, May 19, 2009
    #10
  11. Sverre

    David Lyon Guest

    On Tue, 19 May 2009 13:29:47 +0100, "A. Cavallo" <>
    wrote:
    > 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?
     
    David Lyon, May 20, 2009
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Parvinder
    Replies:
    6
    Views:
    780
    Thomas G. Marshall
    Feb 27, 2005
  2. Dave
    Replies:
    2
    Views:
    497
  3. George P
    Replies:
    3
    Views:
    709
    Alex Martelli
    Sep 11, 2004
  4. David Pratt
    Replies:
    4
    Views:
    351
    David Pratt
    May 13, 2006
  5. Replies:
    1
    Views:
    15,297
    drobert_bfm
    Nov 27, 2007
Loading...

Share This Page