Control: tags -1 moreinfo On Sat, 21 Dec 2024 at 14:36, Bastian Blank <wa...@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?
