multiple executable files

[Fiedzia]

I was trying to see if I could use subuser to package rust compiler. However, being fairly complex bit of software, it comes with several commands that must be available to users (rustc, cargo, rustfmt and probably more). Executable field seemd to accept only single value. How should I approach this?

[timthelion]

I don't have any one perfect solution to this problem. When I packaged the haskell platform, I created a dummy executable which just forwards commands like this:

#!/bin/bash
$1 "${@:2}"

Then a person could add a subuser named hp and call commands like hp cabal init and hp ghc --help. However, I have moved away from this method in my subsiquent packages. For example, Freecad is written in Python and C, but rather than creating a "Python/C" image that I would then call to build FreeCAD, I created a FreeCAD-dev image which has all of the specific dependencies required to build and run freecad. It also has all of FreeCAD's normal dependencies, like the ability to display windows. The FreeCAD-dev image's executable is bash. I can then do all of my development and testing in a "wellishly" (That is a fake word: "well" = good, "ish" = somewhat, "ly" = creates an adverb) contained environment which has all of those pesky FreeCAD dependencies installed. Once I am done developing in my FreeCAD-dev image, I create a new image FreeCAD which starts SUBUSER-FROM-IMAGE FreeCAD-dev and just downloads the FreeCAD source and builds it. The FreeCAD image then has freecad as it's executable.

[Fiedzia]

Dummy executable may work, but in this case all tools using compiles expect it to be named rustc. Maybe different name would do, but name+parameter would probably not be accepted by all tools that need to use it..

Could we make executable field a list ["/usr/bin/rustc", "/usr/bin/cargo", ...] or a dictionary {"/usr/bin/rustc": "rustc1.5", "/usr/bin/cargo": "cargo1.5", ...} to define host aliases?

[timthelion]

OK, I think that I can do something. I think that I can create a permission called entry-points which will be a dictionary like:

{"rustc1.5": "/usr/bin/rustc",
 "cargo1.5": "/usr/bin/cargo"}

Then, using this new interface https://github.com/subuser-security/subuser/issues/250, the user would be able to do something like:

$ subuser subuser add rust rust@http://friedzia.org/rust.git
$ subuser shortcuts expose-entry-points rust

Once they did that they would be shown a list of default entry points and asked to either accept or edit the list.

With those two commands, rust would be installed and all of the paths would be in place. What do you think?

[Fiedzia]

Pretty much what I need. I am not sure about forcing user to specify entrypoints - or to even know all of them. There can be many, and it still should be userfriendly.

[timthelion]

Unfortunately, it is absolutely necessary that the user see end-points and be able to modify them. What if a subuser had a "cp" endpoint which could, in some casses, over-ride the "cp" command. And the subuser had permission to view the current directory. Then the subuser would be able to see any file that was copied. Security is still an important thing for me ;) even in casses where the main goal is portability.

[Fiedzia]

To be clear, I was referring to the need of running "subuser shortcuts expose-entry-points rust" for each entry point. Is there a way to say "expose-all-defined-entry-points? I'm just trying to keep it simple for user. As for overriding cp - sure, I assume packages will only expose only what's needed. Some mechanism is needed to control this ($PATH may do), but I do not want user to perform this role (at least not without some help).

[timthelion]

I had envisioned the expose-entry-points command as exposing all defined entry points. The UX would be as follows:

$ subuser shortcuts expose-entrypoints rust
Rust would like to expose the following entry points:
 rust1.5
 cargo1.5
Would you like to:
 A - accept
 e - edit exposed entry points
Please enter your selection [A/e]: A
Exposing entry points for subuser rust.

If the user entered e, then a text editor would be launched from $EDITOR which would allow the user to edit subuser rust's permissions.json file and then the user could change which entry points were exposed.

[Fiedzia]

Looks good for me. Perhaps a check if anything in $PATH doesn't clash would be helpful.