| Summary: | unify colorization in Gentoo | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | alex_y_xu, dev-portage |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Get portage to use baselayout functions | ||
|
Description
SpanKY
2007-08-16 05:23:57 UTC
Maybe it would be a better idea for portage to use the einfo family of functions baselayout provides? shell programs can . /etc/init.d/functions.sh to get einfo as usual C programs just have to link to -leinfo to get them. To override the colours, simply set the following env vars to the ASCII escape codes you desire. ECOLOR_GOOD ECOLOR_WARN ECOLOR_BAD ECOLOR_HILITE ECOLOR_BRACKET We don't actively load them from a config file as such. If we need todo this, then maybe something in /etc/env.d is a better option? Using einfo and co from baselayout isn't an option, mainly (but not only) due to the logging functionality in the portage versions. Might be a better idea to move /etc/portage/color.map to another location and let baselayout use it. Created attachment 128288 [details, diff]
Get portage to use baselayout functions
This won't work with baselayout-1 of course, but it does demonstrate that what I said both reasonable and possible.
Another alternative is to get the logging you require into baselayout.
As I said, the logging isn't the only reason. Other reasons are: - no hard dependency of portage on baselayout - portage also has (and uses) python versions of einfo and co - no more support for color.map (= regression) (In reply to comment #4) > - portage also has (and uses) python versions of einfo and co So between portage and baselayout we now have 3 implementations of einfo. Isn't that just a little bit redundant? > - no more support for color.map (= regression) So we a layer into your isolated functions to use the color.map if it exists. The hard dep on baselayout is the only argument you've stated that I cannot possibly argue against. But it does also mean we only have one implementation of einfo versus 3. Oddly enough you have that hard dependency anyway - binutils-config, gcc-config, perl-cleaner and many others use /etc/init.d/functions.sh Guess what? python-updater uses it too and portage uses python. My statement of having portage use baselayout not being an option wasn't something to negotiate. That said, what is the real point of this bug anyway? As I understood it, Mike wants a single source for color definitions (currently split between whatever baselayout does and portages color.map). And the simple fact is that color.map is a superset of the few values baselayout uses (and I'd argue that it's used by more people). (In reply to comment #5) > So between portage and baselayout we now have 3 implementations of einfo. > Isn't that just a little bit redundant? Portage uses colors for more than just e* functions. All we want to share is the color definitions. I forgot to mention that the current color.map format is documented in `man 5 color.map` (the man page is only included with >=portage-2.1.3). (In reply to comment #8) > Portage uses colors for more than just e* functions. All we want to share is > the color definitions. And baselayout-1 defines said colours as shell variables - they're defined in functions.sh as ${GOOD} ${BAD}, etc. We always have done. baselayout-2 also provides a C function to get these too. But as you don't actually want to use any of that, would you be willing to load a shell file? I'm more for environment variables myself. As I've already stated, $ECOLOR_GOOD works with baselayout-2 and will affect every program that uses einfo and friends as provided by baselayout - which by some strange co-incidence is every program in Gentoo except for the package managers. (In reply to comment #10) > But as you don't actually want to use any of that, would you be willing to load > a shell file? I'm more for environment variables myself. As I've already If the colors for the E* functions are all that we'll share then I guess environment variables are good enough. We could define the default ECOLOR_* variables in /etc/env.d and the user can always drop a new file in there to override them if they want. > stated, $ECOLOR_GOOD works with baselayout-2 and will affect every program that > uses einfo and friends as provided by baselayout - which by some strange > co-incidence is every program in Gentoo except for the package managers. IIRC, back when the gfbsd project started, they didn't use our baselayout so it wasn't possible for portage to use it's functions. For lower level system packages like package managers, we often have to try to minimize dependencies due to various issues like this. (In reply to comment #11) > IIRC, back when the gfbsd project started, they didn't use our baselayout so it > wasn't possible for portage to use it's functions. For lower level system > packages like package managers, we often have to try to minimize dependencies > due to various issues like this. You're right, they had a bandaged hyrbid system that worked for them. However, they still provided /etc/init.d/functions.sh for things like gcc-config to use :) So every baselayout or baselayout-a-like has provided this. I *think* portage uses g-f now? |