Who even knows how it works these days?
So I just did it by hand, more like 50k...
Microsoft does stuff like this all the time, deprecating good .NET libraries for stupid ones just because of God knows what reasons (none of them intelligible to non-political folk).
If it really was a dependency, I think a bug should be filed against the package. :/
Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.
The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too.
There's no mechanism for identifying such minimum possible dependencies.
Is this true? It seems like this would be one of the most obvious essential features of any package management system.
Of course, it may be that the maintainer always specifies the latest version,
But it takes over with dependencies of newer versions than necessary.
Er, yes there is, and there has been for at least the last 12 years, and probably more.
Requires: python >= 2.6.1
Requires: python
The automatic mechanism in place is to run ldd, identify the list of libraries used by the executables distributed, and mark those libraries as dependencies. Since the package is build on your newer, Debian 5 package, it requires (automatically) the newer libfoo (like python-2.7), while it would have worked just fine with the older libfoo (python-2.5).
>> Yes there is
> What you mention is a manual mechanism
I agree, they should ditch the automatic ldd method. I justy wanted to correct the inaccuracy of saying there wasn't a way to specify min versions.
Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs
Seriously. Use virtualenv (and virtualenvwrapper).
There is a bunch of stuff that doesn't (shouldn't) belong to the OS, but still be runnable by all users without all of them needing a copy in their $HOME directory.
If you're writing quick ad-hoc scripts and don't have time to package, /usr/local/bin.
Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it. We can't and probably don't want to change that, so we'll need to live with it.
Use virtualenv. if you need to to, install a quick Python 2.6 package that slots alongside your OS package rather than removing it - using RHEL 5 as an example, you'd install 'python26' alongside your existing 'python' package.
> Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it.
The OS doesn't need python. It is some package you have installed that needs python, like Gnome(py-gtk2) or KDE(py-qt), for your desktop environment or some application you decided you needed. If you don't understand what program on your server required python to be installed, then you shouldn't be administering a server. Having large numbers of language interpreters and compilers on a server can be considered a security risk, since after someone gains access, that provides him or her a large number of options of what kind of code he or she can run. Even having a C compiler is a risk, since code can then be compiled into programs already present on the system. Security should be first in mind when developing an application server.
On the other hand for a development environment, there should be nothing stopping any distribution from installing multiple language interpreter versions. The default `/usr/bin/python` or `/usr/local/bin/python` can be a symlink to python25, python26 or python27, and when the user needs to run a different version, they explicitly call the binary with the version number. This whole virtualenv method just to parse a configuration file of a program not written in python seemed a little excessive.
No. The installer and packaging system need Python. Anaconda and Yum depend on it. Try removing it and see. You cannot install a minimal RHEL or Fedora system without Python. I am fairly sure this applies to other distros too.
If the Linux distro you choose doesn't meet your needs, why would you continue to use it? If your Fedora install requires it to be one way, but that doesn't fit the need of the server, it would like one should reconsider why they are using that distro.
If you're running 10,000 machines you don't make changes that you haven't regression tested and aren't committed to supporting. Effectively, you'd need to write your own package manager, maintain your own repository and deal with upstream yourself... You'd be Red Hat.
If you don't understand what program on your server required python to be installed, then you shouldn't be administering a server
Quite.
You can blow away your /usr/local and start from a new ports tree and build it all back up without adversely affecting the system.
Everything system related is in /bin, /sbin, /usr/bin, /usr/sbin depending on whether it needs to be accessible when the system has just / mounted or when /usr is mounted as well.
So in single user mode with just / mounted you have access to various different utilities. Mount /usr and you can expand upon that.
Back in the old days when FreeBSD required perl in its base system switching to a newer version didn't break any of the base system tools (or maybe I just never noticed).
There is something nice about a layout that is properly documented and makes sense: http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...
* 'python' remains installed, at version 2.4
* 'python26' is now installed, into separate folders.