Other Help Topics :: Python on DSL



Mikshaw
Quote
I did not intend to imply that others should do things the way I do them, although the term "use aliases" does sound more imperative than I had intended.

I was a little more concerned about the implication that symlinks are somehow undesirable, insecure, inconvenient, or unsafe, especially with respect to /usr/local. The part about /usr/bin-lib-include I certainly understand and agree with.

Quote
In all honesty I don't believe more than a few people here are in a situation where they admin a multi-user system...

That's an understandable assumption (especially with dsl).

------
s_i:
Quote
For example, below are the symlinks belonging to Wine...

Heh. Serves you right for trying to run Windows programs under Linux.
Quote
once I delete this directory, only the symlinks are left. These will become broken links - I think broken links are shown with a different colour from normal links when running `ls`
And, just for the sake of saying something else, in mc they are shown with an exclamation point as a file type (if you have file types enabled).
In the case of deleting directories or unmounting uci packages, a usable alternative to a symlink is a wrapper script. I use wrappers for several of my frequently used ucis. The wrapper first checks for the existence of the executable before trying to run it. In some cases, the wrapper chooses a different executable if the desired one is not found. For example, this checks for the vim uci package, but runs vi if it's not found:
Code Sample
#!/bin/bash
if [ -x "/opt/vim/bin/vim" ]; then
exec /opt/vim/bin/vim -c "syntax on" "$@"
else
exec vi "$@"
fi


Quote
.tar.gz seems to imply that the package will be self-contained, whereas if you are downloading a .dsl, the expectation is to have files scattered all over /usr/local.
Specifically, .tar.gz mydsl packages install into /opt, which is already part of ramdisk. This does not necessarily mean that they will be self-contained, but the limited target directories pretty much force this to be the case. It is possible to spread out the files, but this is not recommended and can easily result in failure of the program installation.
The .dsl packages install in the standard unix/linux locations, which to many people might appear to be a mess. There is a logic to this, though, since grouping similar file types together allows for much quicker access to executables and shared resources (fewer directories needed to search for libraries, headers, and executables). Comparing this to Windows, for example, it is much easier to run an arbitrary command without needing to know where it is...Windows needs a full path to work in most cases.
That said, I'm not a huge fan of this logic when it comes to complex programs that include many files. In those cases I'd rather have a self-contained package (or nearly so...shared libraries would be the exception) that can be easily moved, removed, or updated without the need to search for support files. The binary releases of Firefox and Blender are good examples of this.
Well, that certainly looked like a case of light blue touchpaper & stand back...

Interestingly (or not), compiling hplip and python to /usr/local did not solve the lib problem - "/usr/local/lib/cups/backend/hp" complained about various missing libs requiring linking them one by one /usr/local/lib -> /usr/lib.

But... compiling hplip to /opt/hplip and python to /opt/python worked after I copied the contents of /opt/hplip/lib/python2.3/site-packages to /opt/python/lib/python2.3/site-packages and all this without needing to link libs anywhere (but adding /opt/hplip/bin and /opt/python/bin to the path).

original here.