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 <
zbys...@in.waw.pl> 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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to