Alternative support for iotop; add c-iotop.

[dmarto]

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the quality requirements: YES

Local build testing

• I built this PR locally for my native architecture, x86_64-glibc

Not sure, if I handled the alternatives correctly, so I am open to suggestions; I have tested switching back-and-forth and using both with no issues.

[CameronNemo]

the alternatives changes will not work correctly from what I can tell

see e.g. void-linux/xbps#253

just the new package, without adding or messing with the alternatives, would be more likely to be accepted.

[dmarto]

Hey, thanks for the suggestion, honestly I was split between several options:

• this one, that should cover everything and hopefully work (based on my knowledge of xbps)
• having both iotop pkgs conflict with one another, and adding some info in the pkg desc
• what you suggested and using another name for the binary and keeping the old pkg as is
• removing the old one and leaving only the iotop-c

I ended up on this path, as I don't feel the other two are proper or quality solutions.

---

My "view" of the process, may be very, very wrong, but "It worked on my Machine (ТМ)" :D

The old iotop is replaced before the new one; and thanks to the conflicts of the c-iotop pkgs, the group can't be registered before the old one gets handled by its own pkg and registers the group. That way, there is no need to worry about order of operations.

Anyway, I am willing to wait on a comment from the guys that better know the internals of xbps and figuring out a way to make it work with alternatives - as the OG iotop is a de-facto standard and well at least in some cases I can see the preference to have them both.

[leahneukirchen]

Provided in 6c14d25 as iotop-c like the other distros.