iB::Topic::Python on DSL

	Damn Small Linux :: Damn Small Linux Board The DSL Forums

» Welcome Guest
[ Log In :: Register ]

Damn Small Linux Board » Damn Small Linux » Other Help Topics » Python on DSL

		Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
		Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic

Pages: (5) </ 1 2 3 [4] 5 >/

[ Track this topic :: Email this topic :: Print this topic ]

Topic: Python on DSL, it is for Sabnzbd

< Next Oldest | Next Newest >

^thehatsrule^ Offline

Group: Members
Posts: 3275
Joined: July 2006

Posted: July 25 2007,19:46

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.

lucky13

Group: Members
Posts: 1478
Joined: Feb. 2007

Posted: July 25 2007,20:09

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)

--------------
"It felt kind of like having a pitbull terrier on my rear end."
-- meo (copyright(c)2008, all rights reserved)

stupid_idiot Offline

Group: Members
Posts: 344
Joined: Oct. 2006

Posted: July 25 2007,21:17

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

mikshaw

Group: Members
Posts: 4856
Joined: July 2004

Posted: July 25 2007,21:54

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.

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html

mikshaw

Group: Members
Posts: 4856
Joined: July 2004

Posted: July 25 2007,22:01

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.

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html

22 replies since June 07 2007,14:07

< Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (5) </ 1 2 3 [4] 5 >/

Damn Small Linux Board » Damn Small Linux » Other Help Topics » Python on DSL