Radare2: Fix R2pm for release builds

[radare]

r2pm should clone and pull for a specific date if using r2 from release (r2 -v| grep git)

[imyxh]

I'd be happy work on an implementation for this in the shell script, but I worry that checkout by date isn't the optimal solution. What if some function is renamed very close to a release date, and plugin creators are just a day or so behind the refactor?

I think if we make checkout by date the default behavior, we should probably also implement an option to install from a specific commit of a package. Then, at least, users can override when necessary.

-i,install <pkgname> [commit]
install or update package in your home (pkgname=all);
if [commit] is specified, install from package's git commit hash [commit];
else if r2 is a release build, install package from latest commit at date of r2 release;
else install package from git master

Also, getting the date of the release from GitHub looks like it might be annoying. Off the top of my head, the best I can think of is

curl -gs "https://github.com/radareorg/radare2/releases/tag/$(r2 -qv)" | grep relative-time | ...

which would break if GitHub changes their html. I imagine that it would be a smarter idea to write date-of-release information into r2 -v.

Thoughts? Another option, of course, is to just ask plugin writers to tag their damn packages with corresponding r2 versions. :)

[XVilka]

Shellscript r2pm is outdated, please contribute to https://github.com/radareorg/r2pm instead.

[imyxh]

@XVilka okay, will do; corresponding issue is r2pm/67. I assume the golang version of r2pm is eventually going to be merged into this repository? It's been in development for a while so I wasn't sure if it was to be merged in future or if it's just a side thing for compatibility.

[XVilka]

It will not be merged in this repository, but shell script will be removed (once r2pm.go is done) yes.

[radare]

i think r2pm.c will be done before r2pm.go and i dont want to remove the shellscript because r2pm.go doesnt uses the same syntax so many packages that i use wont be there.

r2pm.go is almost 2 years old and its still unusable, r2pm.sh took me one night to do and its still rocking. i have 0 hope in Go

On 22 Mar 2020, at 02:25, Anton Kochkov [e-mail] wrote:

It will not be merged in this repository, but shell script will be removed (once r2pm.go is done) yes.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/radareorg/radare2/issues/11353#issuecomment-602132268, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG75FSXO5C2LYHGJZCAX2TRIVSHZANCNFSM4FSZX5NA.

[XVilka]

Shellscript is non-portable solution (no Windows). We need portable
solution. Go gives libs out of the box - for https, GitHub API, zip files,
etc. It will become way more complex in pure C.

On Sun, Mar 22, 2020, 21:33 radare [e-mail] wrote:

i think r2pm.c will be done before r2pm.go and i dont want to remove the
shellscript because r2pm.go doesnt uses the same syntax so many packages
that i use wont be there.

r2pm.go is almost 2 years old and its still unusable, r2pm.sh took me one
night to do and its still rocking. i have 0 hope in Go

On 22 Mar 2020, at 02:25, Anton Kochkov [e-mail]
wrote:

It will not be merged in this repository, but shell script will be
removed (once r2pm.go is done) yes.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <
https://github.com/radareorg/radare2/issues/11353#issuecomment-602132268>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAG75FSXO5C2LYHGJZCAX2TRIVSHZANCNFSM4FSZX5NA
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/radareorg/radare2/issues/11353#issuecomment-602201522,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABRT7PPPKOMJCXAZE2AC7DRIYHSXANCNFSM4FSZX5NA
.

[imyxh]

@XVilka, wouldn't libcurl provide all the functionality we need from C? If we ask plugin authors to simply tag their repos, downloading could be as simple as a GET request to the appropriate GitHub URL.

[XVilka]

@imyxh surely there are libraries for C, but then the problems arise:

• Crossplatform building, preferably without any of radare2 source dependencies (for Go it's just go get or whatever similar)
• Building statically binaries, with Go it's easy as one command for ANY supported platform
• r2pm.go is supposed to be small independent binary (like rustup) to keep your radare2 and cutter installations updated, along with plugins
• We want to have simple binary packages support with r2pm - https://github.com/radareorg/r2pm/issues/7
• And so on.

[radare]

System(curl) is better than libcurl same goes for system(git) vs libgit. I dont want to add those dependencies to r2 when we can just call the system programs

On 22 Mar 2020, at 20:11, Ian Huang [e-mail] wrote:


@XVilka, wouldn't libcurl provide all the functionality we need from C? If we ask plugin authors to simply tag their repos, downloading could be as simple as a GET request to the appropriate GitHub URL.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[qbarrand]

r2pm.go is almost 2 years old and its still unusable, r2pm.sh took me one night to do and its still rocking. i have 0 hope in Go

Not exactly the same products, are they? :)
r2pm in Go would also call those programs, and allow for a variety for package types (including binary archives for Windows) with a YAML syntax. See https://github.com/radareorg/r2pm/blob/master/docs/packages.md#schema for an idea of what a package file might look like. Note that there is exactly zero dependency on sh!

I am certainly to blame for the lack of progress of r2pm, but I see that there's been some interest lately, which is great. I must confess that comments like https://github.com/radareorg/radare2/issues/11353#issuecomment-602201522 are not encouraging, though.

[thestr4ng3r]

I am certainly to blame for the lack of progress of r2pm

No actually you are the one reason there HAS been progress in r2pm at all.

About C, I don't see a big reason to switch to C now, Go is easy enough to learn.