# r2pm notes ## Site directory The site directory is owned by `r2pm`: ``` $R2PM_SITE ├── installed/ │ └── pkg1.yaml │ └── pkg2.yaml │ └── pkg-from-cli.yaml ├── r2pm-db/ │   └── db/ │ └── pkg1.yaml │ └── pkg2.yaml └── sources/ (either cloned repositories or the extracted binary packages) ``` It is automatically created by `r2pm` if it does already exist. ## Environment variables |Name |Description |Default value | |--------|-----------------------------|------------------| |`EXEDIR`|Where to put executable files|`$HOME/.local/bin`| |`LIBDIR`|Where to put libraries |`$HOME/.local/lib`| ## Packages To install a package, `r2pm` must find a *package description file* in the YAML format. Package description files are either provided by the database or can be fed to the application directly: `r2pm install -f </path/to/description/file>`. After installation the YAML file is added in a folder called `installed`. ### Source The package source is represented in the YAML file by the `source` field. In this section, `$SUBDIR` means `${R2PM_SITE}/sources/${package_name}`. ```yaml source: # can be type: git repo: https://github.com/radareorg/r2pm # or type: archive url: https://somewhere.com/archive.zip ``` |`type` |Additional fields|Steps |Example | |---------|-----------------|------------------------------------------------------------------------------------------------------------|--------| |`git` |`repo` |clone the repo from the `repo` YAML field into `$SUBDIR` and run the install commands |`r2dec` | |`archive`|`url` |download the archive from `url`, extract the archive contents into `$SUBDIR` and run the install commands |None yet| ### Dealing with output files After the `install` commands have been ran, it might be desirable to install the output files into a `radare2` installation. We use the `out` YAML field to figure out what needs to be done: ```yaml out: - file: <a file name relative to $SUBDIR> type: exe | lib-shared ``` The value of the `type` field can be any of the following: |`type` |File type |Destination| |------------|------------------|-----------| |`exe` |An executable file|`$EXEDIR` | |`lib-shared`|A shared library |`$LIBDIR` | ## Installing a package To install a package, `r2pm` must find a *package description file* in the YAML format. Package description files are either provided by the database or can be fed to the application directly `r1pm install -f </path/to/description/file>`. After installation the YAML file is added in a folder called `installed`. ## Uninstalling a package A package can be uninstalled by running `r2pm uninstall ${package-name}`. The following steps will be ran: - Remove all files copied following the `out` YAML parameter - Remove `${R2PM_SITE}/sources/${package-name}` - Remove `${R2PM_SITE}/installed/${package-name}.yaml` # OLD stuff ### Setting environment variables when running the install commands **Question:** Should we set stuff like `$R2PM_PLUGDIR`? -> What do you mean? ## `r2pm`-managed directory Where `r2pm` holds the `db`, `installed` and `git` directories. **Questions:** - can we call it *site* directory? -> Maybe homedir? Localdir? Installdir? - should there be `--site-dir` CLI flag? -> If you need it for debug yes, otherwise I don't think it's required. We can always add it later if needed ## CLI **Questions:** - should we keep printing out messages with [`log`](https://golang.org/pkg/log/) or use it just for optional messages? - should we write the output to `stdout` or `stderr`? -> Which output? Please add details of the various output in a table and we'll give comments. ## init to be removed At first launch r2pm performs init routine so init command has to be removed. If connectivity is missing, the user should be provided with a message telling him he needs connectivity or can perform init manually by doing X and Y. # How to detect r2 paths It's required because many plugins rely on it. For example, r2dec: `r2 -H` to find the location of r2 libdir Question: Is it the proper way to do it? Should we change r2dec compilation? Alternative: r2dec asks r2pm where r2 is located Problem: r2dec would require r2pm to compile ^ [QB] why? - Check for r2 in PATH 1. Linux & MacOs - pkg_config 2. Windows - Tu cherches dans le dossier courant et le PATH, et tu demandes a l'user de specifier l'endroit si il ne trouve pas (je crois que tous les softs sous windows te demandent de specifier ou sont tes libs, genre cmake -DMYSOFT_LIB_PATH=D:\Tools\MySoft) ``` [antide@archlap ~ ]$ pkgconf --libs libr -L/home/antide/.local/lib -lr_core -lr_lang -lr_search -lr_asm -lr_util -lr_reg ``` Note: For user path like `~/.local/lib` it requires to have `export PKG_CONFIG_PATH="/home/antide/.local/lib/pkgconfig"` for obvious reasons # Multiple `r2pm` version - `r2pm` manages a `r2pm` directory somehwere - if it sees something that was generated by an earlier version (upgrade), it migrates it to the latest version - if it sees something that it does not understand, it fails - upon error, support should recommend that the user uses the latest version # Rewriting `Makefile`s `Makefile`s should be standalone and work without `r2`. ## To find the `radare2` headers - on Linux / macOS, use `pkg-config --cflags r_asm` - on Windows: maijin - same as How to detect r2 paths For this to work, one has to set `$PKG_CONFIG_PATH`. ## To find the `radare2` libraries - on Linux / macOS, use `pkg-config --libs r_asm` - on Windows: maijin - same as How to detect r2 paths ## QUESTIONS - Should r2pm detect plugins installed manually? --> How could it do that? if one `.so` per plugin it could maybe, but sounds tricky. --> Yeah probably not reliable... Maijin - It could be done via a directive in the yaml like "check" or "test" for existing installation of a given package. That mechanism could also be used to check if the installation succeeded or failed, this could only be simply stuff like ls /lib/package.so or /bin/r2dec -v | grep vXXX (obviously these tests/checks would have to be done per OS). But for now the simpler way is If it has been installed via r2pm -f yes, otherwise no detection. ### Archived questions - What if the user has Cutter installed but not r2? --> is that possible? how does that change vs. using `r2pm` in the standalone mode? - What if the user has Cutter installed (with the shipped `libr2pm.so`), but also uses r2pm from the command line (downloaded separately)? --> not a problem - the same functions are called --> Then the only problem is the r2pm version handling right?