# 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?