[csw-pkgsubmissions] newpkgs openldap, openldap_client, openldap_d(...)
Maciej (Matchek) Blizinski
maciej at opencsw.org
Wed Nov 3 14:07:40 CET 2010
No dia 2 de Novembro de 2010 16:19, Philip Brown <phil at bolthole.com> escreveu:
> I think it could be improved, by visually tying those "next two lines"
> to the output below.
> Putting in a sub-section marker or something? Otherwise, they just
> seem part of the prior two lines.
Yes, that's true, there currently isn't a visible separation between
the general bit and the bits specific to error tags.
Separating the error tags isn't very easy, as I haven't arrived at a
data structure general enough. There are cases where it's
straightforward what to suggest. In other cases, it isn't as clear
any more, for example when one problem can be solved in two different
ways. For example, a binary might need libgcc_s.so.1, which is
provided by both gcc3corert and gcc4corert. Checkpkg needs to present
an alternative: you need to depend on either gcc3corert or gcc4corert,
and you have to determine yourself, which one should it be. (Barring
very specific heuristics such as "no /opt/csw/gcc4 in RPATH, therefore
probably gcc3corert".)
> Also, I think it would be helpful if the use of '#' was more consistent.
> It's nice that the "start section" comments have the "#" prepended to them.
The idea behind the hashes is that they might be part of what you cut and paste.
As far as visual separators are concerned, the problem is that there
are too many small sections to be separated. There are generally
three kinds of messages:
- Description of the problem (let's call them D)
- GAR lines to add if you want to fix the issue (F)
- GAR lines to add if you want to override (O)
The current message model is:
"""
Introductory bit
D1
D2
D3
...
F1
F2
F3
...
O1
O2
O3
...
General ending explaining that you shouldn't override the errors
without thinking first.
"""
Another model could be:
"""
Introductory bit
D1
F1
O1
D2
F2
O2
...
Ending bit
"""
My idea behind grouping all Fs and Ds was that it's easier to work with.
Another idea was to only display Ds and Fs, and display the Os only on
demand, for example:
checkpkg --display-overrides foo.pkg.gz ...
> So it's then a bit visually confusing when the lower down stuff, such as
>
> "Applying the overrides and analyzing the results.
> If any of the reported errors were false positives, you can override t"
>
> does not have the "#".
The "Applying the overrides..." message could be entirely removed, it
doesn't say anything interesting to the user.
> Basically, I'm suggesting that there be more visual separation between
> output lines of
> "Here's stuff you might want to actually cut-n-paste into your GAR recipie". vs
> "here's stuff you just should scan through.
>
> So that's my suggestion, do what you like with it :)
Thanks, I'd be interested what people think about the message grouping issue.
More information about the pkgsubmissions
mailing list