| 1 |
On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote: |
| 2 |
> >>>>> On Wed, 29 Sep 2021, A Schenck wrote: |
| 3 |
> |
| 4 |
> > On 9/28/21 8:36 AM, Michał Górny wrote: |
| 5 |
> >> [WW] some message |
| 6 |
> >> [EE] other message |
| 7 |
> >> [QA] hell if i know what this is |
| 8 |
> >> |
| 9 |
> >> I've also added more colors to explicitly distinguish einfo from elog, |
| 10 |
> >> and ewarn from eqawarn. Then, I've replaced most of '>>>' and '!!!' |
| 11 |
> >> used by Portage with four-character versions to keep messages aligned. |
| 12 |
> >> The 'zings' used for merging files remain three-character, so now it's |
| 13 |
> >> easily possible to distinguish messages from installed file list. |
| 14 |
> |
| 15 |
> > Didn't expect to be the only dissenting opinion on something like this |
| 16 |
> > but. . . Some applications parse portage output looking for these |
| 17 |
> > 'zings'. At very least app-portage/kuroo does it this way; there must be |
| 18 |
> > others, right? This is obviously not the ideal way to get information |
| 19 |
> > out of portage, but it's been stable for the 15 years Kuroo has existed. |
| 20 |
> > 10-ish years ago dol-sen started some work on building and API for |
| 21 |
> > portage, but then got sucked into core portage development to the point |
| 22 |
> > of abandoning their GTK+ portage GUI porthole, which was the original |
| 23 |
> > impetus for an API, and as far as we know, the API never made it to the |
| 24 |
> > point it could replace parsing the output. |
| 25 |
> |
| 26 |
> If only the length of the >>> and !!! strings is a problem, then why not |
| 27 |
> leave them alone and go for single-letter tags instead? Like this: |
| 28 |
> |
| 29 |
> [.] einfo |
| 30 |
> [I] elog |
| 31 |
> [W] ewarn |
| 32 |
> [E] eerror |
| 33 |
> [Q] eqawarn |
| 34 |
> |
| 35 |
> The only problematic one is [Q] instead of [QA] which is no longer |
| 36 |
> self-explanatory. Then again, only devs and experienced users should see |
| 37 |
> eqawarn messages. |
| 38 |
|
| 39 |
fwiw eqawarn is currently displayed for everyone in a similar manner |
| 40 |
as einfo, just not post-emerge/elog without adding to ELOG classes. |
| 41 |
|
| 42 |
If users aren't hiding build logs entirely, they may notice those |
| 43 |
done at the end (often shown after size report) -- and possibly |
| 44 |
think it's a problem. |
| 45 |
|
| 46 |
Not to say whether [Q] vs [QA] would help with this much so I have |
| 47 |
no strong opinion here. |
| 48 |
-- |
| 49 |
ionen |
Archives