The glusterfs-ganesha package depends on pcs (for executing HA cluster tasks), pcs depends on python-clufter which in turn pulls in nano.

/bin/vi is one of the most common fallback editors in case $EDITOR is not set. Maybe that can be used if returning an error message is not more suitable.

Thanks for the very first upstream issue filed :)

Having editor reliably available is meant to provide full user experience
in an interactive use of clufter tool (expected to be delivered with
clufter-cli package in the suggested RPM packaging) out of the box,
for when there's something wrong with the clufter internals and invalid
CIB is generated, so the user can still relatively conveniently intervene.
Nano was picked as this default choice, because it is deemed best
size/friendliness tradeoff (we know these ':q' jokes).

Now, since you are rather talking about pcs-pulled dependency, which
is the library part of clufter (python*-clufter), this full experience is
not that necessary there and hence the dependency on editor could be
dropped for these and only kept for clufter-cli -- I would perhaps still
prefer nano as a default fallback though, power users should have
EDITOR exported in their profiles, anyway.

Does it sound reasonable?

BTW. there're better solutions for Fedora as one can use weak deps
(Suggests/Recommends) or boolean expressions
(vim-minimal or nano or ...).

Note that systemd also prefers user-friendly nano:

$SYSTEMD_EDITOR ... systemctl will try to execute well known editors in this order: nano(1), vim(1), vi(1)

Just because SystemD does something, doesn't mean it's right.... in fact, I already have one issue (related but not dependent on this issue) where SystemD does the wrong thing O_o and I have to work around it with a hammer

Point is, just because you prefer vim or emacs doesn't mean it is
a good choice for casual users not familiar with various obscure ways
to control the editor (/me is in vim camp but really doesn't dare to
annoy anyone with this opinionated preference), and as already mentioned,
power users presumably have EDITOR also set.

Regarding your systemd (note the spelling) affair, that's what respective
issue trackers are for.

I want to remove nano as it caused issues for me and my team(s), as it's not needed when there are preferred editors available... and yes I've already tried to re-open the SystemD (intentional spelling) bug, so no need to re-hash that issue here, I just had to make the point here that SystemD (intentional misspelling) and it's choices shouldn't be taken as the gospel of systemadmin...

Nano isn't necessarily "userfriendly" for me it's keypress choices are a pain and caused several (mis)configuration failures for me, so it's a matter of opinion, I just don't see the need for nano in this case where it could execute the user environment variable EDITOR set to the choice of the sysadmin/user/etc.

It's especially an unintentional problem when you've installed and configured software (Using Ansible/etc.), and then your system breaks with the removal of an unused and inconsequential package like nano (part of the cleanup Ansible scripts)... and that is the reason it should NOT be a hard dependency, not because somebody else thinks it better/worse, but because it's not a needed piece of software to operate clufter, just an "advised"/optional package .

Sure, have you noticed the above proposal to move the dependency to clufter-cli which is something not installed (not even transitively) for being a dependency of pcs?

Ok, I've made the declared change: 9dbc5b1
That made it to v0.75.0 I just released, it will take some time till
it propagates to Fedora, CentOS and friends.

Hope this helps.

Thanks! Placing the editor dependency in clufter-cli looks like a good approach to me too.