/opt setup

[GoogleCodeExporter]

Please consider adding attached /opt/setup.sh script.

As result of discussions on #inferno we come to this general scheme about how 
to install /opt packages:

 * both /opt/vendor/package and /opt/package supported (second is useful for alternative naming schemes like /opt/vendorpackage and for switching different implementations by binding /opt/vendor/package-someimpl to /opt/package)
 * commands become available by bind -b /opt/vendor/package/dis/cmd to /dis, plus bind -b /opt/vendor/package/dis/wm /dis/wm etc. for any subdir in dis/ except cmd/ and lib/ - this have limitation by doesn't supporting deeper directories (like dis/wm/brutus/), but doing recursive binds is too complex and probably useless thing
 * man pages become available by bind -b /opt/vendor/package/man/* to /man/*
 * .m files left in /opt, and included by full path like 'include "opt/vendor/package/module/package.m";' (this require adding -I/ option to limbo); PATH constant in .m files also contain full path in /opt - this allow to avoid any conflicts at low cost, plus having full path in include is ease way to see non-standard dependencies
 * dis/lib/*.dis files also left in /opt

So, all opt packages can be automatically "installed" with binds in this way. 
After that user may unbind some package manually in case this package overwrite 
some standard application in /dis while user need standard app (but in most 
cases if user install /opt package which provide, say, "ls" command, then user 
probably *want* to replace standard ls with that one).

This way using /opt for users become as simple as:
1) add "bind -b opt /opt" to ~/namespace
2) add "/opt/setup.sh" to ~/profile

It may have sense to rename this script to something like /dis/bindopt.

Original issue reported on code.google.com by powerman...@gmail.com on 27 Apr 2011 at 9:16

Attachments:

• setup.sh

[GoogleCodeExporter]

is there a reason to include the .sh suffix instead of having just /opt/setup?

Original comment by Charles....@gmail.com on 27 Apr 2011 at 9:34

• Changed state: Accepted

[GoogleCodeExporter]

it might also be more flexible to use "run /opt/setup" so it runs in the 
shell's environment

Original comment by Charles....@gmail.com on 27 Apr 2011 at 9:37

[GoogleCodeExporter]

no, there no reason, feel free to rename it as you like
and there are no need run - it contain "#!/dis/sh -n"

Original comment by powerman...@gmail.com on 27 Apr 2011 at 9:58

[GoogleCodeExporter]

'include "opt/vendor/package/module/package.m";'

this seems clumsy, and perhaps ties package.m too much to a specific place in a 
hiearchy. i'll pop the /opt/setup into place even so while thinking what might 
be better.

Original comment by Charles....@gmail.com on 27 Apr 2011 at 1:27

[GoogleCodeExporter]

Original comment by Charles....@gmail.com on 27 Apr 2011 at 1:27

• Changed state: Started

[GoogleCodeExporter]

while thinking about better alternative please keep in mind there needs in 
running limbo both inside emu and in host os. and in host os we usually unable 
to use a lot of binds to make sure limbo will find all files in same dir. so, 
if we'll bind module/ and lib/ somehow inside emu, then outside emu limbo will 
still see many different dirs

Original comment by powerman...@gmail.com on 27 Apr 2011 at 1:42

[GoogleCodeExporter]

In baac80642ba4 you've mention opt(1) and opt(6) in /opt/README, but these man 
pages (and script) wasn't included.

Original comment by powerman...@gmail.com on 16 Jun 2012 at 6:20