Deployment your software for OS Inferno
Unfortunately, there is no built-in mechanism for distributing and installing additional software in OS Inferno . If you have written a module for Limbo or a full-fledged application, and you want to share it, then there are few distribution options:
As you understand, the first option is, in fact, not an option. :) This is a return to the cave. The second option is used, for example, for all software in the mjl repository . But this approach also has unpleasant limitations caused by the fact that your files are simply copied to the system directories
I want to propose an alternative approach based on the DJB's slashpackage . Update: this approach was recently adopted by infferno developers, so that it can already be considered not alternative, but official. :)
In this approach, all 3rd-party modules / applications should search for their files and files of other non-standard modules / applications inside the
With this approach, to install a new module / application system-wide (ie, from root), one command is enough! For example, if the module / application is laid out in the Mercurial repository on Google Code :
A regular user installation locally requires two commands (it is assumed that a subdirectory opt / powerman / has been created in the user's home directory in advance):
The fact is that the repository already contains compiled .dis files in the subdirectories of
In order for your application to use the wrong version of the 3rd-party module / application, which by default is in
To compile and install (for example, if you made local changes to the 3rd-party code of a module / application), run
')
It depends on how the package is distributed, but in general it comes down to one or two commands. For example, for the same Mercurial it comes down to normal
in the
There is simply no place. I think you have already guessed how this is done, but I cannot deny myself the pleasure to write it:
Oh, this is a complicated operation, without a database in any way - why are we worse than rpm / apt / portage? :)
As you can see, managing such packages to the user is really easy and convenient. Now let's see how to use them.
Is it a bit long? It can be shortened with the help of the sh functions (function definitions should be entered once in the profile):
Update: Another method is described below, see /opt/setup.sh.
This will immediately work if the modules are installed locally, i.e. in the subdirectory
To create a package installed in
All paths are relative, for example:
Update!
Another option for using 3rd-party modules and applications is to connect them using bind from
Update2!
The improved version of the above
In addition, a selection of mkfiles similar to the standard ones, but supporting work with / opt-projects, and recommended for use in your projects, was developed if they either use / opt-modules or are installed in / opt: inferno-opt-mkfiles themselves .
Several simple modules / applications written in this style can be found by searching for “inferno contrib” on Google Code .
Update: An example / opt project has been laid out for use as a template for a quick start of their projects: inferno-opt-skel .
Russian language description Limbo
Russian wiki for OS Inferno, translations of documentation
- just upload your files to any site, and let users manually install them to their system wherever and how
- use the same mkfile / mkconfig files that are used by standard modules and applications in
/appl/
As you understand, the first option is, in fact, not an option. :) This is a return to the cave. The second option is used, for example, for all software in the mjl repository . But this approach also has unpleasant limitations caused by the fact that your files are simply copied to the system directories
/dis/ , /module/ , etc. as a result. (just like standard modules and applications from /appl/ ):- if * nix is ​​used as the host OS, and Inferno is installed system-wide by root or your distribution package's package manager, then to install additional modules / applications, you need root privileges (either
sudo mkon the host OS, orsudo emuand nativemk) - Global installation is inconvenient if you want to use a modified version of these modules / applications for your application.
- global installation is inconvenient if different applications need different versions of the same module (mjl solves this problem in the traditional * nix way by adding the major version number to the module name, which is not very elegant and leads to names like “util0.m”)
- Uninstallation turns into a non-trivial operation, which ultimately leads to littering of system directories.
- names of modules / applications of different developers may conflict (however, this problem exists in * nix / win, and it can be circumvented using subdirectories in
/dis/and/module/with the name of the developer or his site)
I want to propose an alternative approach based on the DJB's slashpackage . Update: this approach was recently adopted by infferno developers, so that it can already be considered not alternative, but official. :)
Directory structure
- Create a global catalog for all 3rd-party software
/opt/. Update: The directory already exists in the current version of Inferno. - Separate subdirectories for each developer / organization are created in
/opt/, and subdirectories for each module / application are created in them to avoid name conflicts between different developers (eg/opt/powerman/hashtable/). - A directory structure similar to the system one is created in the directory with the module / application:
dis/dis/lib/module/appl/cmd/appl/lib/- etc. if necessary
In this approach, all 3rd-party modules / applications should search for their files and files of other non-standard modules / applications inside the
/opt/ directory.Package management
Installation
With this approach, to install a new module / application system-wide (ie, from root), one command is enough! For example, if the module / application is laid out in the Mercurial repository on Google Code :
# hg clone https://inferno-contrib-hashtable.googlecode.com/hg/ $INFERNO_ROOT/opt/powerman/hashtable A regular user installation locally requires two commands (it is assumed that a subdirectory opt / powerman / has been created in the user's home directory in advance):
$ hg clone https://inferno-contrib-hashtable.googlecode.com/hg/ opt/powerman/hashtable ; bind opt /opt The fact is that the repository already contains compiled .dis files in the subdirectories of
dis/ and dis/lib/ , and with this approach, after copying the directory with the module / application to /opt/ its .dis files automatically appear exactly where and should be after the "installation".Select a specific version / use a modified version
In order for your application to use the wrong version of the 3rd-party module / application, which by default is in
/opt/ , it is enough to connect the necessary version to /opt/ before launching your application (and thanks to namespaces in Inferno this will not affect other applications that just need the default version): ; bind ./my-modified-hashtable/ /opt/powerman/hashtable/ ; ./my-app (Re) build package
To compile and install (for example, if you made local changes to the 3rd-party code of a module / application), run
mk install in its directory (for example, /opt/powerman/hashtable/ ). In this case, compiled dis-files will be installed in the dis/ subdirectory of this module / application.')
Update
It depends on how the package is distributed, but in general it comes down to one or two commands. For example, for the same Mercurial it comes down to normal
$ hg pull $ hg update in the
opt/powerman/hashtable/ directory. In this case, from the repository will be pulled up including. updated .dis files in opt/powerman/hashtable/dis/ , and this is essentially a package upgrade.Uninstall
There is simply no place. I think you have already guessed how this is done, but I cannot deny myself the pleasure to write it:
; rm -r /opt/powerman/hashtable Get a list of installed 3rd-party software
; ls /opt/* Get the list of files included in the package
Oh, this is a complicated operation, without a database in any way - why are we worse than rpm / apt / portage? :)
; fs print /opt/powerman/hashtable/ Use of these modules / applications
As you can see, managing such packages to the user is really easy and convenient. Now let's see how to use them.
Applications
; /opt/powerman/retrymount/dis/retrymount Is it a bit long? It can be shortened with the help of the sh functions (function definitions should be entered once in the profile):
; fn retrymount { /opt/powerman/retrymount/dis/retrymount $* } ; retrymount Update: Another method is described below, see /opt/setup.sh.
Modules
include "opt/powerman/hashtable/module/hashtable.m"; load HashTable HashTable->PATH; This will immediately work if the modules are installed locally, i.e. in the subdirectory
opt/ . If the modules are installed globally at /opt/ , then you need to run limbo with the -I/ option for the native limbo, or -I$INFERNO_ROOT when starting limbo from the host OS. This can also be configured once, for example for the native limbo: ; fn limbo { builtin limbo -I/ $* } Development of these modules / applications
To create a package installed in
/opt/ you need to follow a few simple rules:module / hashtable.m file:
PATH: con "/opt/powerman/hashtable/dis/lib/hashtable.dis"; appl / {lib, cmd} / *. b-file:
include "../../module/hashtable.m"; load HashTable HashTable->PATH; mkfile:
All paths are relative, for example:
MODULES=\ ../../module/hashtable.m\ DISBIN=../../dis/lib /opt/setup.sh
Update!
Another option for using 3rd-party modules and applications is to connect them using bind from
/opt/ to standard directories. How to do this simply and universally is not entirely clear, but there is a partial solution. The script shown below (I usually keep it in /opt/setup.sh ) will connect all the commands and man pages from /opt/* to /dis/ and /man/ . Thus, the teams can be run simply by name, without a full path like /opt/powerman/retrymount/dis/retrymount and the documentation for 3rd-party applications and modules can be viewed using standard tools. #!/dis/sh -n load std for d in /opt/*/man/* /opt/*/*/man/* { or {ftest -d $d} {raise continue} n := `{basename $d} bind -b $d /man/$n } for d in /opt/*/dis/* /opt/*/*/dis/* { or {ftest -d $d} {raise continue} n := `{basename $d} and {~ $n lib} {raise continue} and {~ $n cmd} {n=''} bind -b $d /dis/$n } Update2!
The improved version of the above
/opt/setup.sh now available as an inferno-opt-setup project. The functionality is divided into two scripts: /opt/setup/cmd and /opt/setup/man , which can be used independently.In addition, a selection of mkfiles similar to the standard ones, but supporting work with / opt-projects, and recommended for use in your projects, was developed if they either use / opt-modules or are installed in / opt: inferno-opt-mkfiles themselves .
Examples
Several simple modules / applications written in this style can be found by searching for “inferno contrib” on Google Code .
Update: An example / opt project has been laid out for use as a template for a quick start of their projects: inferno-opt-skel .
Links
Russian language description Limbo
Russian wiki for OS Inferno, translations of documentation
Source: https://habr.com/ru/post/87460/
All Articles