---
# System prepended metadata

title: r2pm notes

---

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