Option to install old versions of packages for compatability

[imyxh]

Issues like r2ghidra-dec/76 seem to happen all the time. Because r2pm installs packages from git master, and those packages are usually made to be compatible with the latest radare2 master, it seems that r2pm can really only be considered secure and compatible when used with radare2 from git.

As a result, those who are using the latest stable (or older) release of radare2—which I am sure is a massive portion of the userbase—are left with plenty of packages that either won't compile or could even possibly have bugs to be discovered later on. As an example, I currently can't install r2ghidra-dec under radare2 4.3.1 because a function was renamed in r2 upstream three days ago, and the r2ghidra devs responded very quickly with the refactor.

Not exactly sure what the best idea would be here. Packages often don't create tagged releases, and if they did, they might not align well with Radare2 releases. Perhaps it would be a good idea if we were to create an r2pm -ii <pkg> command that would checkout R2PM_GIT to the date that r2 says it was built under r2 -v. This could be implemented with git rev-list.

A caveat against the above idea is that a stable release of r2 could've definitely been built after the release date, and some changes may have happened in between. To resolve that, I imagine that we would have to use the output of r2 -qv and some git magic to figure out the date the last commit of that tag was pushed, then checkout packages to that date. I would guess that this would work something like 99 % of the time, and would only fail if a last-minute change was pushed to the r2 repo before the tagged version and plugin creators didn't respond in time.

Anyway, it seems like a complicated mess—ideally, I think plugin creators could just make tagged releases that correspond to radare2 versions. Is that something we'd want to enforce/suggest?

Edit: the simplest solution I can think of right now, which leaves some work to the user, would just be to create a --commit=1234abcd option on installation that could be passed to git during/after the cloning process. Users would have to figure out what commit works for their version of radare2.

[radare]

https://www.endpoint.com/blog/2014/05/19/git-checkout-at-specific-date

[expenses]

Yes please! This is a real pain.

[lberrymage]

I too would like to see this. I use the stable version of radare2 on Arch Linux, mostly because the git version in the AUR is dated and I don't want to install from source and potentially clutter my filesystem. I've personally run into r2ghidra-dec/76, so something like what's being suggested would be greatly appreciated.

[imyxh]

Golang r2pm equivalent of radare2/11353. I think we should bring the discussion there to solve that one, and then figure out what to do with the go version of r2pm.

Edit: never mind....

[imyxh]

I've personally run into r2ghidra-dec/76, so something like what's being suggested would be greatly appreciated.

Note that there's actually a new r2ghidra-dec package in the community repo, which seems to work fine for now. :) I think until we solve this issue, it's easier for users of stable versions to just package these plugins themselves with PKGBUILD / whatever equivalent.

Meanwhile: I have to say that I'm a little skeptical of the checkout by date idea. Trying to guess when plugin creators are ready to publish for a certain r2 version seems dangerous.

How about something more database-side? Just as an example:

name: r2dec
type: git
repo: https://github.com/wargio/r2dec-js
desc: "[r2-r2pipe-node] an Experimental Decompiler"

versioning: git_tags

install:
  - make -C p

uninstall:
  - make -C p uninstall

Just with an extra database variable to set, plugin packagers directly could specify whether stable versions of r2 pull from corresponding git tags, or by date, or if it should just be ignored altogether, etc.

[imyxh]

Ah, we could actually implement the above but change the current functionality even less. Referencing the package schema, all we would have to do is add a {{ .R2Version }} variable.

Example:

---
name: my-package  # must be unique and equals to the file name
version: {{ .R2Version }}

install:
  windows:
    source:
      type: zip
      url: http://a-random.url/zip-archive-{{ .R2Version }}.zip
# [...]
  linux:
    source:
      type: git
      repo: git@github.com:username/project.git
      ref: {{ .R2Version }}
# [...]

If r2 is installed from git, R2Version is set as master; else, it's set as the version of radare2, like "4.3.1". Plugin maintainers simply have to tag their releases with the corresponding version in git, or if it's a zip plugin, put it in the filename.

I think this would be a lot better than checking out by date and all that, and I assume we'd barely have to touch the r2pm code to work this in. Any comments? I don't know Go (yet) but I'm happy to spend some time implementing this if anyone thinks it's a good idea. :)

Edit: if package maintainers want to release an update to an old package they can always move the tag or simply use branches instead.

[qbarrand]

Referencing the package schema, all we would have to do is add a {{ .R2Version }} variable.

This sounds fine 👍