Other Help Topics :: Python on DSL



it is getting off-topic, but I'll respond here...

All 3 quoted use of /usr/local basically say the same thing... the quotes for RedHat and Debian applies to their package management (which corresponds as expected).  /usr/local is for the local sysadmin, and not for official distributed packages of the distro.  Hence why the default compilation path in source tarballs is usually in /usr/local

Quote
I know DSL is a little different because of extensions like UCI and UNC and because /opt is used in frugal for persistent partition, but that doesn't obviate the reasons for why /usr/local exists.
Afaik  persistent opt isn't needed anymore... (and use of it would be a hybrid setup).  I think the main difference between /opt and /usr/local is that /opt has all of their applications self-contained in their own directory.

Quote
An alias would require a full path
not true... maybe (not) for some shells?

Quote
It's still no more secure adding a link to any other directory in PATH like /opt/bin than it is in /usr/local/bin -- same net effect.
I think mikshaw was just commenting on using /opt/bin is better for DSL for symlinks, since /opt is initially on /ramdisk.
Quote
I think mikshaw was just commenting on using /opt/bin is better for DSL for symlinks, since /opt is initially on /ramdisk.

His statement was much broader than that: "...also prefer the convenience and safety of not needing to mess with the base system (of _any_ distro) unless absolutely necessary..."

There may be circumstances in which it's impractical to use symlinks, but those are exceptions to the rule. It's certainly not a bad, unsafe, insecure, or inconvenient idea for standard hard drive installs (of "_any_ distro").

(edit: fixed punctuation)
Yes, but since there are already so many symlinks in /usr/local/bin to start with, I think it's less confusing for certain extensions to limit their symlinks to /opt/bin. For example, below are the symlinks belonging to Wine - it is obvious that those symlinks that begin with 'wine-' are from Wine, but some things are more confusing, like 'function_grep.pl', 'uninstaller', 'wmc', or 'wrc'.
Code Sample

function_grep.pl  widl            winebuild    wineg++           wineserver
msiexec           wine            winecfg      winegcc           wineshelllink
notepad           wine-kthread    wineconsole  winelauncher      winhelp
progman           wine-preloader  winecpp      winemaker         wmc
regedit           wine-pthread    winedbg      winemine          wrc
regsvr32          wineboot        winedump     winepath
uninstaller       winebrowser     winefile     wineprefixcreate

I agree with you that whether you use /usr/local/bin or /opt/bin, the program will still run.
I would argue that putting an extension under /opt/package_name is more convenient for the purpose of removing the software - `rm -rf /opt/package_name` will do - as opposed to separately removing /usr/local/bin/files, /usr/local/lib/files and /usr/local/share/files. The latter is very easy to do if you have the experience, but I think it will be difficult for a newbie. In contrast, if I use /opt/package_name, 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`, IIRC.
The counter-argument is that this can be done in /usr/local also - the following can be done when configuring the software package when compiling: `./configure --prefix=/usr/local/package_name` For a .dsl package, this is possible. This can be done if the extension author chooses to do so. Anyway, due to conventions in DSL, .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.
Please forgive me if the above sounds incoherent - It is very early in the morning (just got up).
It was not a recommendation of what I think should be done, nor a suggestion that the symlinks are a bad idea, but merely my personal preference. It is a choice to limit whatever configuration possible to my own home directory in all distros I use. This allows me to easily port my settings, symlinks, and whatever else makes the system easier to handle, to other distros, saving me from having to recreate the same symlinks and wrappers every time I try a new distro or upgrade an existing one (I tend to install fresh rather than upgrade...just another personal preference/habit). The "safety" relates to the fact that limiting changes to my home directory means I have no concern about complications that might arise from tweaks and experiments. If I mess something up, the worst case would require only starting with a fresh home directory.

In the case of sharing with other users I agree it would be a different issue, but one I did not bother to bring up. In all honesty I don't believe more than a few people here are in a situation where they admin a multi-user system, and those that do don't have any reason to listen to me ramble on about things they already know (and probably have better/different ideas about).

The main point, however, was to suggest that there is no smartest way to handle files installed in /opt, but that there are various methods to choose from. Some methods might be more appropriate depending on the situation, so it would be useful to understand some of the differences between them.

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.
Quote
I think it's less confusing for certain extensions to limit their symlinks to /opt/bin
If a mydsl app is installed into /opt, it is (or should be) a tar.gz, uci, or unc. The unc packages are joined with system directories already, so there is no reason to do /opt/bin. The uci and tar.gz packages should never, and this one is not just opinion, never install to files to /usr or /bin anyway.  If it's a *.dsl package that installs into /opt, somebody made a mistake (at least until tar.gz is made obsolete).  What the user does after the package is installed is his own business, though, so if that's what you were implying then you can ignore this post.
Next Page...
original here.