mikshaw
Group: Members
Posts: 4856
Joined: July 2004 |
 |
Posted: July 25 2007,15:29 |
 |
Have you tried to see if the Python 2.5 package will work?
As far as I know, older Python mydsl packages are only runtime files, which probably means compiling programs with them isn't going to be successful even if you make the directories writable.
| Quote | | is there a smarter way to deal with this than symlinks to /usr/bin-lib-include and/or adding /opt/whatever/bin to the path (which is anyway limited to the terminal window in question)? |
The smarter way, in my opinion, would be to try to understand why you need to do these things and when to choose one way over the others.
Personally I'm not at all into using symlinks in /usr/bin-lib-include. These directories are initially read-only in DSL. I like to try keeping them that way, and also prefer the convenience and safety of not needing to mess with the base system (of _any_ distro) unless absolutely necessary. Most changes of this kind can be made to files in your home directory, keeping system files untouched.
Modifying variables may be limited to the current terminal, but only if you make those changes from a terminal window. Your startup scripts (.bash_profile, .bashrc, .xinitrc) are there to allow you to make these changes before you open an interactive shell.
You can export the PATH variable from /home/dsl/.bash_profile to include /opt/whatever/bin, and never need to do it manually. Even if that directory doesn't exist (if you don't have the related extension installed at the moment) it's still in PATH for future use. The same can be done with the LD_LIBRARY_PATH for finding libraries.
Another option is to create your symlinks in /opt/bin instead of /bin, /usr/bin, or /usr/local/bin. This directory is already writable and in PATH. The limitation with this is /opt/bin is at the _end_ of path, which means you cannot override a system executable with your own by adding it to this directory. But there are ways to deal with that, too, such as creating /home/dsl/bin and adding that to the _beginning_ of PATH.
Also, use aliases. Aliases are extremely handy, not only for allowing you to run commands easily that are not in PATH, but for running complex or cryptic commands with a few keystrokes (alias nocomment='egrep -v "#|^ *$"'). The limitation here is that aliases are limited to your shell, and are ignored by most other applications.
As far as headers go, I think that is dependent on what you're compiling and how it is compiled, but the only time you need to bother about them is while you're compiling, so it's not such a big deal. When using headers installed in /opt/myapp/include for a C program, typically do "export CFLAGS=-I/opt/myapp/include" before compiling, and "export LDFLAGS=-L/opt/myapp/lib" if there are libraries that are not available in DSL base. In a typical source package with a configure script, "configure --help" will generally tell you what variables apply. I guess you could probably export these variables from a startup script the same way as PATH, though it never occured to me to try it until this moment. But as I said, it's only important while you are compiling.
--------------
http://www.tldp.org/LDP/intro-linux/html/index.html
|
.
DSL Market ,
Great VPS hosting provided by Tektonic
