iproute2 configure says : [...] Usage: $0 [OPTIONS] --color <never|auto|always> Default color output configuration. Available options: never: color output is disabled (default) auto: color output is enabled if stdout is a terminal [...] but the ebuild force color output edo ./configure --color=auto --libbpf_force $(usex bpf on off) Why is that ? Thanks Reproducible: Always
auto is not forcing color output? Aside for that -- the ebuild does something many ebuilds do and uses upstream configure options. It isn't intrinsically wrong to pass a configure option to enable a non-default, but supported, setting. Maybe instead we should ask: "what is the problem with autodetecting color"? Is there an issue this causes, that led to you submitting a bug report?
(In reply to Eli Schwartz from comment #1) > auto is not forcing color output? > > Aside for that -- the ebuild does something many ebuilds do and uses > upstream configure options. It isn't intrinsically wrong to pass a configure > option to enable a non-default, but supported, setting. > > Maybe instead we should ask: "what is the problem with autodetecting color"? > Is there an issue this causes, that led to you submitting a bug report? Sorry for using the term "force", it is indeed different than "always" option but in fact the "auto" option does enable color in my terminal. With my dark background terminal with transparency, the color scheme used makes the output unreadable. I can of course add a bash alias to set --color=never but, the previous version of iproute (6.6.0) did not enable color : A patch that enabled color by default in default was dropped (with 6.6.0) : https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af7b77d3b451d7d8b58babb471902d07d20ca803 I quote : "This diverges from upstream defaults for no good reason. Users can set up a shell alias if they really want to enable colors by default."
(In reply to David Duchesne from comment #2) > (In reply to Eli Schwartz from comment #1) > > auto is not forcing color output? > > > > Aside for that -- the ebuild does something many ebuilds do and uses > > upstream configure options. It isn't intrinsically wrong to pass a configure > > option to enable a non-default, but supported, setting. > > > > Maybe instead we should ask: "what is the problem with autodetecting color"? > > Is there an issue this causes, that led to you submitting a bug report? > > Sorry for using the term "force", it is indeed different than "always" > option but in fact the "auto" option does enable color in my terminal. With > my dark background terminal with transparency, the color scheme used makes > the output unreadable. > I can of course add a bash alias to set --color=never but, > the previous version of iproute (6.6.0) did not enable color : Another option would be to adjust your terminal emulator's color palette. If you wish to explore this option, and need assistance, I recommend asking in the IRC channel #gentoo (https://www.gentoo.org/get-involved/irc-channels/) or on the Gentoo forums. > > A patch that enabled color by default in default was dropped (with 6.6.0) : > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=af7b77d3b451d7d8b58babb471902d07d20ca803 > > I quote : > > "This diverges from upstream defaults for no good reason. Users can set up a > shell alias if they really want to enable colors by default." The patch you're referring to patched iproute to unconditionally default to auto color. This did deviate from 6.6.0 behavior as the default at the time was to never color. That said, the approach used in the 6.8.0 ebuild does not deviate from upstream. Upstream modified iproute2 so the default value can be set at configure time. The ebuild is taking advantage of that feature.
/etc/bash/bashrc.d/10-gentoo-color.bash enables colors for grep, ls, vdir, and a few others by creating aliases for said commands or by setting the LS_COLORS environment variable. When coloring is not supported or explicitly disabled no alias is created and command defaults are used. For the previously listed utilities that means no coloring. Should iproute2's coloring be handled in the same manner for consistency?
(In reply to nvinson234 from comment #4) > Should iproute2's coloring be handled in the same manner for consistency? I am not sure that it should be as things stand. That's because I agree with David's implication that the way in which iproute2 employs colour results in an extremely poor degree of contrast. I find this to be the case for any terminal that employs a traditional colour palette (black, red, green, yellow), irrespective of whether transparency is involved. For this reason, I did not appreciate it when Gentoo was applying the patch that Mike later removed and did not welcome yesterday's realisation that colour support is making a comeback. I am also not sure that is reasonable to suggest that users should adjust their terminal palettes to account for the behaviour of one (commonly used) program. Indeed, I already use a Windows-style palette - it is specifically designed to follow tradition while slightly improving contrast levels on modern LCD displays - and I still find the colourised output of iproute2 very hard to read. One could argue that to employ 4-bit colour codes will always produce results that are suboptimal for someone's terminal palette. Nevertheless, I submit that the behaviour of iproute2 is in poor taste and that it amounts to a general issue of usability. Taking ls as a counter-example, the colours that are most commonly seen are, at least, of the bright variety.
Incidentally, someone using the ~arch package was complaining on IRC about it yesterday to the effect of the "ipv6 line" being "totally unreadable" on account of being "dark blue".
The --color=auto option was (silently) added in this version bump: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c7120ac28e255ba135c0fa5b9808a66104e6d6b8 I would guess that chutzpah snuck it in thinking nobody would notice or care. I still maintain my stance that it doesn't make sense to diverge from the upstream default here. However, I don't really want to start a revert war over it. Maybe we (base-system) should vote on the matter?
(In reply to David Duchesne from comment #2) > Sorry for using the term "force", it is indeed different than "always" > option but in fact the "auto" option does enable color in my terminal. With > my dark background terminal with transparency, the color scheme used makes > the output unreadable. Thanks for clarifying. I agree that's a reasonable concern given it was previously enabled, then disabled for the same concern you raise.
From bug 886187: (In reply to Sam James from comment #2) > It's enough of a nicety that I think it's nice to have a USE flag for it, > but I guess doing it by default isn't nice wrt expectations, so will need to > either go for patch Luke suggests or something functionally equivalent with > some -DFOO. Given some people really seem to like it and some people really seem to hate it, I think it makes a lot of sense to say EITHER it is only a bashrc alias, OR it is controllable via a USE flag and defaults to the upstream choice.
A USE flag seems acceptable to me, especially since we now have a configure option to control it.
Given the distro for which some like to say is all about choice, there appears to be a curious cultural disposition towards vendoring preferences that aren't in line with the defaults. If this is going to be keep sneaking back in then I agree with Mike; base-system should just settle this once and for all. In my capacity as a punter, it should already be clear which side I'm on. There would need to be en improvement on the part of iproute2 for me to change my mind. Optics matter.
I interpret the existence of a configuration option as meaning upstream now consider it ready for people to use, so it's philosophically different from patching it. But yes, I agree the colours are poor, even if they're IMO marginally better than nothing. Can I suggest someone report the colour scheme issues upstream first?
(In reply to Sam James from comment #12) > I interpret the existence of a configuration option as meaning upstream now > consider it ready for people to use, so it's philosophically different from > patching it. > > But yes, I agree the colours are poor, even if they're IMO marginally better > than nothing. > > Can I suggest someone report the colour scheme issues upstream first? This is a sensible suggestion. I had previously pondered doing this but my motivation was rather curtailed by having to potentially invest time in arguing with someone who may not be a bastion of good taste to begin with over a feature that I will probably never use. Thinking twice before choosing to use the dim colour variants would probably go a long way.
