[Aptitude-devel] Bug#626829: "Current status" looks like an error warning

[Manuel A. Fernandez Montecelo]

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 jidanni at 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.montezelo at gmail.com>