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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
