Radare2 and Cutter in an unmanageable dependency after project fork

[Henrik Nordström]

I recently took ownership of Radare2 after it was orphaned,
unfortunately unknowing of the current turmult in the Radare2 project.

Now realizing that it has a dependent Fedora package Cutter (cutter-re)
which is at the edge of this turmult. And pushing an update of Radare2
will break Cutter.

It is not a simple clean-cut update to keep the cutter-re package alive
as Cutter has split from the Radare2 project, and in the process forked
Radare2 as Rizin. Updating of Cutter would require Rizin to be packaged
for Fedora.

The Radare2 project in turn have forked Cutter as R2Cutter. But
R2Cutter is not Cutter. And Rizin is not Radare2.

What is the proper action to deal with situations like this?

I see four different paths

1. Keep Radare2 and drop support for Cutter

2. Keep Radare2 and switch Cutter to R2Cutter. R2Cutter is the same
Cutter that currently is in fedora in terms of source, but it's future
is uncertain. And I am not sure if this is possible policy wise without
packaging R2Cutter and retiring Cutter.

3. Get Rizin packaged for Fedora, and with it update Cutter. With Rizin
liklely replacing Radare2.

4. Drop Radare2 and Cutter from Fedora until the dust settles.

I honestly can not say which is the better of Radare2 and Rizin, or
predict which of the two will sutain the better momentum long term as
the project fork is quite recent. But I also doubt it's meaningful to
have both Radare2 and Rizin in Fedora together, would be kind of like
having both LibreOffice and OpenOffice but in the field of reverse-
enginering with too much overlap and similatities while still being
different projects.

Regards
Henrik

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 22, 2021 at 12:32:11AM +0100, Henrik Nordström wrote:
>  I recently took ownership of Radare2 after it was orphaned,
>  unfortunately unknowing of the current turmult in the Radare2 project.
>  
>  Now realizing that it has a dependent Fedora package Cutter (cutter-re)
>  which is at the edge of this turmult. And pushing an update of Radare2
>  will break Cutter.
>  
>  It is not a simple clean-cut update to keep the cutter-re package alive
>  as Cutter has split from the Radare2 project, and in the process forked
>  Radare2 as Rizin. Updating of Cutter would require Rizin to be packaged
>  for Fedora.
>  
>  The Radare2 project in turn have forked Cutter as R2Cutter. But
>  R2Cutter is not Cutter. And Rizin is not Radare2.
>  
>  What is the proper action to deal with situations like this? 
Seems to be a tough call. There's a lot of activity going on in both
projects. There's more commits in rizin, but many of of them are related
to the renaming, so that doesn't matter much. (Many commits are cherry
picked between the projects too.)

There seem to be many good technical ideas in the rizin fork (e.g. the
switch to meson instead of a custom build system, removal of unstable
code), which would make packaging easier. But in such splits it's
always hard to say which fork will "win" (or even if they don't both
die...).

I agree that packaging both doesn't make sense.
My gut feeling is that it's much better to keep the graphical interface
than not, i.e. either cutter or r2cutter should stay in the distro.
The decision about the graphical interface could even determine which
fork is followed.

It'd be nice to get more info from the people involved.

Zbyszek

[Riccardo Schirone]

Hi,

I was the previous maintainer of radare2 and, among other things, an
upstream developer of the same project. I, and others ex radare2
developers, have forked radare2 with Rizin some time ago. That said, I
failed to follow the radare2 6-weeks schedule even before the forking
decision/mess, so I decided to leave that job to someone else that was more
in line with the current upstream radare2 project.

On Mon, Feb 22, 2021 at 9:25 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl&gt; wrote:

>  On Mon, Feb 22, 2021 at 12:32:11AM +0100, Henrik Nordström wrote:
>  > I recently took ownership of Radare2 after it was orphaned,
>  > unfortunately unknowing of the current turmult in the Radare2 project.
>  >
>  > Now realizing that it has a dependent Fedora package Cutter (cutter-re)
>  > which is at the edge of this turmult. And pushing an update of Radare2
>  > will break Cutter.
>  >
>  > It is not a simple clean-cut update to keep the cutter-re package alive
>  > as Cutter has split from the Radare2 project, and in the process forked
>  > Radare2 as Rizin. Updating of Cutter would require Rizin to be packaged
>  > for Fedora.
>  >
>  > The Radare2 project in turn have forked Cutter as R2Cutter. But
>  > R2Cutter is not Cutter. And Rizin is not Radare2.
>  >
>  > What is the proper action to deal with situations like this?
>
>  Seems to be a tough call. There's a lot of activity going on in both
>  projects. There's more commits in rizin, but many of of them are related
>  to the renaming, so that doesn't matter much. (Many commits are cherry
>  picked between the projects too.)
>
>  There seem to be many good technical ideas in the rizin fork (e.g. the
>  switch to meson instead of a custom build system, removal of unstable
>  code), which would make packaging easier. But in such splits it's
>  always hard to say which fork will "win" (or even if they don't both
>  die...).
>  
I can't say which one Fedora should "bet" on or if it should bet at all.
And of course my opinion would be biased :) That said, it is hard at the
moment to keep track of things with Cutter/radare2/Rizin because
essentially there are no C API guarantees (there never were), so you always
have to rebase and re-build/rebase Cutter as well every time there is an
update. There are not even guarantees about commands, so between one
version and the other you could break user radare2/rizin-scripts as well.

I agree that packaging both doesn't make sense.
>  My gut feeling is that it's much better to keep the graphical
> interface
>  than not, i.e. either cutter or r2cutter should stay in the distro.
>  The decision about the graphical interface could even determine which
>  fork is followed.
>  
As Cutter follows Rizin, I think a cutter-re package in Fedora should do
the same to avoid more confusion than there is already and follow Rizin as
well. Otherwise, if you want to stay with radare2, it would be better to
introduce a r2cutter package and remove cutter-re (though as you also said,
I am not sure about its future either).

A new release of Cutter compatible with Rizin is on its way hopefully soon
(it is the first release of Cutter since the fork!) and there is already a
first release of Rizin. If you want to package it I can help with it
(within dev branch we have completely removed the old build system and
moved most external codes to meson subprojects), though I was already using
meson to build radare2 as well because I always liked it more, so it should
be quite easy. I could also co-maintain it, if necessary.

If you need help with anything, please let me know.

Riccardo

[Kevin Kofler]

Henrik Nordström wrote:
>  2. Keep Radare2 and switch Cutter to R2Cutter. R2Cutter is the same
>  Cutter that currently is in fedora in terms of source, but it's future
>  is uncertain. And I am not sure if this is possible policy wise without
>  packaging R2Cutter and retiring Cutter. 
https://fedoraproject.org/wiki/Package_Renaming_Process

>  3. Get Rizin packaged for Fedora, and with it update Cutter. With
> Rizin
>  liklely replacing Radare2. 
That would mean using the same process for the other package.

Unless you want to introduce both stacks in parallel.

        Kevin Kofler