XPost: linux.debian.kernel
Control: tags -1 moreinfo
On Sat, 21 Dec 2024 at 14:36, Bastian Blank <
waldi@debian.org> wrote:
On Sat, Nov 30, 2024 at 11:39:31AM +0000, Luca Boccassi wrote:
See the manpage, you can set COLORFGBG in your shell profile according
to your configuration.
There are no patches or color choices downstream, it's just what
upstream provides, so if you don't like their choice of a default,
please bring it up upstream, we will not carry out-of-tree patches to customise something like this for one particular user, sorry.
The rest of the Debian Kernel team, which is maintainer of this package, talked about this and came ot the following conclusion: this bug nees to
be fixed.[1]
If you wish to discuss iproute2 bugs/MRs/changes in the future, please
do so including me, as I am the maintainer and sole contributor of
this package. Thanks.
Enabling colors by default is a deviation from upstream. Debian also
does not enable colors by default in other low level tools like ls or
grep. In some cases, colors are enabled in default bash configs.
This is explicitly configurable, so it can't really be defined as a
"deviation from upstream" - if it wasn't intended to be configurable,
it wouldn't be. It's normal for package builds to provide build time configuration, and happens all the time, all over the place (including
in the kernel package, otherwise everything in debian/config would be
a 'deviation from upstream').
Other network command line tools such as resolvectl and networkctl
also enable colors by default on TTYs, so prior art is definitely
mixed and not one-sided. And AFAIK there are no explicit rules either
way.
So please either
- restore the upstream default of color disabled by default, or
Sorry, but as already mentioned in this bug, I disagree with this
request, as the output is _much_ clearer with colors. Those who don't
want this, can just trivially disable it, just like with networkctl
and others. The default should provide the maximum usability. Even
with a simple 2 IFs case, due to the density of textual information
reported by these commands, color-highlighting helps tremendously to
given prominence to the important information, so that they jump up to
the eye:
https://i.imgur.com/l46ifzN.png
This is even more true when there are many interfaces on a system.
- use a better usable color scheme (yes, I know this is hard with how
colors work on usual termionals).
Sure, as already mentioned in this bug, the idea of changing the
scheme is fine, but someone needs to precisely say what does not work,
and what it should be changed to. Saying "I don't like colors" is not actionable. Saying, for example, "using the color RED for the 'DOWN'
status of an interface is bad because of <X reason> and should be
changed to <Y color>", would be actionable, but it hasn't happened so
far. If such details were provided I'm sure we can work something out
with Stephen. So, what exactly should be changed, and to what?
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
