Control: tags 588237 + pending
Hi all, I reply primarily to this bug report because the message is slightly different now; but I am including all bug reports and submitters here. The previous incarnation of the message was like "There are 0 new [-1]". 2010-07-06 12:24 jida...@jidanni.org:
Package: aptitude Version: 0.6.3-2+b1 Severity: wishlist At the end of a run we see "Current status ...": # aptitude full-upgrade ... Current status: 2 updates [-17]. # Well it looks very much like something went wrong. So if you are going to say that, then at least have a "No errors occurred' or "All completed successfully" message there too. Also you might as well spell out what those numbers are supposed to mean too.
I agree with arguments on both sides, spelled out in the different bug reports, that I am not going to comment in detail. As a summary, on one side, there is the need of succintness, people often complain about the verbosity of aptitude; and some of the suggestions were not very suitable because the lines are too long, or complicate a lot the translations. I also agree with the other side, that "There are 0 new [-1]" or the new "Current status: 2 updates [-17]" looks a bit like an error, and the phrase can be confusing until one learns with time what it means. I am not sure what's the original rationale to show things in this way, while for example the obsolete packages are listed explicitly (not exactly succint), but anyway, I tried to improve the situation while not changing much the structure of the output, and keeping the rest of the constraints. <bikeshedding time> I thought about these possibilities (numbers invented, possibly incorrect): Current status [in brackets, diff from last update]: 864 new [+34], 345 updates [+102], 13 broken [-1]. Current status: 864 new [+34 diff], 345 updates [+102 diff], 13 broken [-1 diff]. Current status: 864 new [diff: +34], 345 updates [diff: +102], 13 broken [diff: -1]. Current status: 864 new [+34 from last update], 345 updates [+102 from last update], 13 broken [-1 from last update]. Current status: 864 new [+34 from last update], 345 updates [+102], 13 broken [-1]. Some are very long when all numbers are present (which is not always the case), the ones with "diff" accompanying the number are not bad but I didn't like them very much, and the one only stating "from last update" only in the first instance are difficult to implement with the current structure of the code and the internationalisation considerations. Similarly, something added clarifications like: "Current status: 2 updates *available* [-17]" or "Current status: 0 new *packages* [-1]" ...are nice when there is only one element, but quite verbose/tedious when more/all elements are present. </bikeshedding time> Anyway, in the end I changed it only slightly, "aptitude -v update": - old: Current status: 0 broken [+0], 283 updates [+18], 4632 new [+49]. There are 2 newly obsolete packages: libclucene-contribs1, libclucene-core1 - new: Current status: 0 (+0) broken, 283 (+18) updates, 4632 (+49) new. There are 2 newly obsolete packages: libclucene-contribs1, libclucene-core1 Maybe it's only me or a cultural difference, but for me parentheses rather than square brackets, and specially moving it next to the "total" number, is the most obvious way to indicate changes of this kind: gross number and increase/decrease/percentage in parentheses (e.g.: "gross income 800,500 (+33,500)"), rank within a list and change from last year/update (e.g. Wikipedia "List of countries by Human Development Index"), etc. But more importantly, errors are more often between square brackets, and beginning or end of a phrase, not in the middle -- so parentheses and next to the other number makes it quite clear that it's not an error, which is one of the major complaints of these bug reports. So it is a small and perhaps a stupid change that doesn't fit the bill for all, but I find it much more clear/unambiguous this way. I commited it and it will be changed from the next release, unless there are strong objections. Cheers. PS: Such a long text for such a small change and minor bug... sorry :-) But then again, there are at least 3 different bug reports about this, so if we want to close them someday... -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
