From: dmarto <dmarto@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: alternative iotop
Date: Sun, 13 Mar 2022 19:34:31 +0100 [thread overview]
Message-ID: <20220313183431.SVVyX8TxSx5qerq302iukLSM5YnDizo5CWLjhwa-cJk@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-36086@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]
New comment by dmarto on void-packages repository
https://github.com/void-linux/void-packages/pull/36086#issuecomment-1066158102
Comment:
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.
next prev parent reply other threads:[~2022-03-13 18:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 0:34 [PR PATCH] " dmarto
2022-03-12 23:32 ` CameronNemo
2022-03-13 18:34 ` dmarto [this message]
2022-05-03 0:20 ` [PR PATCH] [Updated] " dmarto
2022-07-14 15:07 ` Alternative support for iotop; add c-iotop leahneukirchen
2022-07-14 15:31 ` [PR PATCH] [Closed]: " dmarto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220313183431.SVVyX8TxSx5qerq302iukLSM5YnDizo5CWLjhwa-cJk@z \
--to=dmarto@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).