On 9/29/21 3:58 PM, Francesco Riosa wrote: > Il giorno mer 29 set 2021 alle ore 23:52 A Schenck > <lane_and...@hotmail.com <mailto:lane_and...@hotmail.com>> ha scritto: > > On 9/28/21 8:36 AM, Michał Górny wrote: > > Hi, everyone. > > > > I know I'm going to regret asking this... but I've prepared a > change to > > the Portage output format and I think it asks for a wider discussion > > than internally in Portage team. > > > > The primary problem with the current output format is that different > > kinds of messages differ only in color. This makes them > > indistinguishable without colors and hard to grep. ago's been > asking > > for a better way to grep for QA warnings and this is pretty much > what > > motivated me to do this. > > > > The proposed new format distinguished message types both using > colors > > and strings. This is roughly inspired by Xorg logs. For example, > > instead of: > > > > * some message > > * other message > > * hell if i know what this is > > > > You get: > > > > [WW] some message > > [EE] other message > > [QA] hell if i know what this is > > > > I've also added more colors to explicitly distinguish einfo from > elog, > > and ewarn from eqawarn. Then, I've replaced most of '>>>' and '!!!' > > used by Portage with four-character versions to keep messages > aligned. > > The 'zings' used for merging files remain three-character, so > now it's > > easily possible to distinguish messages from installed file list. > > Didn't expect to be the only dissenting opinion on something like this > but. . . Some applications parse portage output looking for these > 'zings'. At very least app-portage/kuroo does it this way; there > must be > others, right? This is obviously not the ideal way to get information > out of portage, but it's been stable for the 15 years Kuroo has > existed. > 10-ish years ago dol-sen started some work on building and API for > portage, but then got sucked into core portage development to the > point > of abandoning their GTK+ portage GUI porthole, which was the original > impetus for an API, and as far as we know, the API never made it > to the > point it could replace parsing the output. > > It wouldn't be worth blocking progress for one application that > not many > people use, but assuming there are others that will also break > with this > change. Are we sure there's no way to support ago's (very > valuable) work > without breaking other things? > > -A > > > Kuroo is already a quite complex application that parse portage > output. A quick grep seems to show that changes needed are quite > manageable. > Also the parsing should be more accurate with proposed changes. > Rather it should be easy for the application to know in advance which > format the output will be. > There is also the opportunity to have a flag that enable (or disable) > the augmented output, but IMHO this should be done only if the added > complexity is NIL > > $ grep -c -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1 | grep > -v :0$ > kuroo-1.2.1/TODO:1 > kuroo-1.2.1/src/history/history.cpp:3 > kuroo-1.2.1/src/config/configdialog.h:2 > kuroo-1.2.1/src/queue/queuelistview.cpp:1 > kuroo-1.2.1/src/core/scanupdatesjob.cpp:1 > kuroo-1.2.1/src/core/global.h:2 > kuroo-1.2.1/src/core/packageinspector.cpp:4 > kuroo-1.2.1/src/core/packageversion.h:2 > kuroo-1.2.1/src/core/etcupdate.h:1 > kuroo-1.2.1/src/core/portagedb.cpp:2 > kuroo-1.2.1/src/core/scanhistoryjob.cpp:3 > kuroo-1.2.1/src/core/global.cpp:1 > kuroo-1.2.1/src/core/dependatom.h:2 > kuroo-1.2.1/src/core/emerge.cpp:8 > Alas and alack, just searching for regular expressions isn't enough, there are places that use QString::startsWith and contains and mid, &c. with literal QStrings. Tthere might be "spooky action at a distance" in some fifteen year old code that used some esoteric method to parse output because it was hip like -funroll-loops, and that could takes years to track down and fix despite best efforts to fix all the obvious QReg(|ular)Ex(|pression)s.
If the idea is to clean up old code that admins haven't looked at in years because it "just worked"™, that's valid too; treecleaner project is laudable for that. But if breaking things isn't the goal, then we should consider if there are options to keep things working. Regarding "added complexity": it would probably mean parsing one additional optional command line argument or make.conf / environment variable, then initialize format strings in elog/messages.py or output.py or something. It would be a lot easier to figure out how if the patch was available on free infrastructure rather than just looking randomly at portage code. > > > > > > > > The PR doing this is: https://github.com/gentoo/portage/pull/759 > <https://github.com/gentoo/portage/pull/759> > > > > Example screenshot: > > > > https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png > > <https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png> > > >
OpenPGP_signature
Description: OpenPGP digital signature
