Update list hides important details

[Yuri Khan]

Since Ubuntu Raring, update-manager no longer shows any useful information by default. I click the Update Manager icon in the indicator area, select “Show updates”, it shows a list of application names and “Xubuntu base”, with download size in the right-hand column. To see exact package names and changelogs, I have to expand the “Xubuntu base” node, expand the “Technical description” area and click through each package.

This new display format is a regression for me. In Precise, the list was flat and displayed application names (package descriptions), package names and download size, all in the main list, which only required me to scroll through to see the list of updates and quickly decide if I want to update now or defer until a more convenient moment; in the new version, I am confused by multiple packages that have identical descriptions.

As a user familiar with package naming conventions, I would like to see the package names and possibly versions (both installed and available), in the list of updates. On the other hand, the download size of each individual package is of low importance to me, as I have a fast and unlimited Internet connection.

I therefore suggest that the list of columns should be configurable (even if via dconf-editor only), and that columns be added for package name, installed version and available version.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dmitry Kann (yktooo)]

I really hate the way UpdateManager displays updates now.

[Ben Cordes (cordes-ben)]

Strongly agree that I would like to be able to pick which columns are displayed on this screen.

[Jethro Beekman (jethrogb)]

Here is a post from the designer of this "improvement":
http://mterry.name/log/2013/01/22/software-updater-changes-in-ubuntu-13-04/

The screenshots really say it all. Would you rather be notified that an "easy to use distributed version control system" is being updated or that "bzr" is being updated?

[Matthew Paul Thomas (mpt)]

Michael Terry and myself may share initials, but I'm the one to blame for the design. ;-)

Containers get blamed for their contents. When we introduced Notify OSD, people reported bugs against it about apps that had always sent too many notifications. Gradually the apps were fixed. And when we introduced Ubuntu Software Center, people reported bugs against it about packages that had always been in the wrong category. Gradually the packages were fixed.

Now with Software Updater, people complain about packages that have poor synopses. Yes, and they always did. The example of Bazaar is a particularly flagrant one: the name of the software is not "easy to use distributed version control system", and it is not "bzr" (though that is the terminal command), it is "Bazaar". <http://bazaar.canonical.com/en/> The package is just wrong.

As long as package names can't contain spaces or capital letters, they often won't be the actual name of the software. The most practical place to put the actual name is in the synopsis, which is what Software Updater shows by default.

I agree it would be nifty to have an optional column showing the package name, as well as an optional column showing the version number. These would probably be toggled from the View menu.

[Yuri Khan (yurivkhan)]

> The most practical place to put the actual name is in the synopsis, which is what Software Updater shows by default.

No, because that would violate Debian Policy, item 3.4.1 The single line synopsis[1]:

> Do not include the package name in the synopsis line. The display software knows how to display this already, and you do not need to state it.

[1]: http://www.debian.org/doc/debian-policy/ch-binary.html#s-synopsis

[Matthew Paul Thomas (mpt)]

I didn't say the package name, I said the actual name. bzr vs. Bazaar. gnome-control-center vs. System Settings. xorg vs. X.Org X Window System. jackd vs. JACK Audio Connection Kit. In many cases the package name and actual name are similar, but that same Debian policy prohibits them from being identical.

[Yuri Khan (yurivkhan)]

I will quote once more from the Policy. 3.4, The description of a package:

> The description should describe the package (the program) to a user
> (system administrator) who has never met it before so that they have
> enough information to decide whether they want to install it.

In other words, it’s the phrase with which a package introduces itself: “Hi! I’m [firefox], a [Safe and easy web browser from Mozilla].” “Hello! My name is [bzr], I am an [easy to use distributed version control system]”. Note how the description extends on the package name and does not (and need not) make sense without it.

When I installed Ubuntu for the first time, I knew no preinstalled packages by name and it might be convenient if they introduced themselves at first, second, maybe fifth update. Now that I’ve been using Ubuntu for 6 years straight, it’s getting silly.

If you want to argue that bzr should be named bazaar, no problem. File a bug against bzr, so that it be renamed and bzr made a transitional dummy package.

But please do not ask that bzr be *described* as “Bazaar”: this description says nothing to help me decide if I want it.

The solution is not to put program titles into the description, it is to show package names *along with* the description.

BTW lintian complains not only at package name included literally in the synopsis line, but also with minor changes, e.g. in letter case. So e.g. putting the word “Firefox” in the synopsis won’t fly.

[Matthew Paul Thomas (mpt)]

Just as you have confused the package name with the actual name, you also seem to be confusing the synopsis with the description as a whole. You claim that a package description is "the phrase with which a package introduces itself", with an implicit "I am a/an" in front of it. Presumably you meant the synopsis, not the whole description; but regardless, I see no evidence for that anthropomorphism.

You also claim that "the description extends on the package name and does not (and need not) make sense without it". But that is directly contradicted by the policy: "in many situations the user may only see the synopsis line - make it as informative as you can". That is precisely the case here: the synopsis is all Software Updater shows by default.

Now, if Debian policy prohibited (1) the package name from being the actual name (as it often does), (2) the synopsis from including anything similar to the package name, and (3) any separate standard field from containing the actual name, then the policy would be perverse. The only way for the software's real name to appear in a software listing would be to ensure that the package name was substantially different from the real name, just so that the real name could be included in the synopsis! To return to the Bazaar example, the Bazaar package could have the synopsis "Bazaar version control system" if its package name was "bzr", but not if its package name was "bazaar".

Fortunately it's not the policy being perverse, just lintian. The synopsis aready does include the actual name in the X.Org X WIndow System and JACK Audio Connection Kit examples I gave.

[Yuri Khan (yurivkhan)]

OK, there are three pieces of information that is present in all packages: the package name, the description synopsis, and the extended description, and there are restrictions on how they interact. (Not actually restrictions as in MUST NOT in the RFC 2119 sense, but a strong SHOULD NOT). The Policy does not talk about the actual name.

3.1: The package name must be unique.

3.4: The description as a whole must be descriptive. (Duh.)

The description synopsis should contain the most important information for such cases when the extended synopsis is not displayed, such as the “apt-cache search” output, one line per package.

3.4.1: The description synopsis should not be redundant when displayed along with the package name. I interpret the “Remember that in many situations the user may only see the synopsis line - make it as informative as you can” part as “the synopsis line must be reasonably descriptive in absence of the extended description”, not as “the synopsis line can be displayed without the package name in sight”.

3.4.2: The extended description is not a continuation of the synopsis; it needs to stand on its own. Presumably, it is displayed in a separate pane or as a separate text section. Also presumably, getting the extended description requires some user effort.

For the Update Manager, I think we can agree the extended description is mostly irrelevant: it makes no sense to display it for all packages. Its place is in the details pane, along with the relevant changelog excerpt.

The question is about the package name and the description synopsis. You defend the position that the description synopsis is sufficient.

However, the synopsis cannot contain the package name, by 3.4.1. And many packages have actual name as the package name, so, in general, the synopsis will not contain the actual name. It follows that, until and unless a new field containing the actual name is added, we need the package name displayed at all times, because it’s the closest that we have.

[Matthew Paul Thomas (mpt)]

So, we agree on everything except the meaning of the word "only" in 3.4.1. To be fair, this is obviously unclear to many packagers too: while many include the actual name in the synopsis (for example in gcc, emacs, and libstdc*), many others avoid it (for example in f-spot, squirrelmail, and strace).

It is true that for some low-level and command-line packages the actual name is identical to the package name, lower-case and all: for example, libcanberra, cdparanoia, and gksu. However, I posit that in real-world updates, most of those cases are contained inside "Ubuntu base" and therefore hidden by default anyway -- especially so once bug 1166230 is fixed.

[Paolo Montrasio (paolo-paolomontrasio)]

I just noticed this after upgrading from 12.04 to 16.04.

I have to expand every single item in the list to know what it's going to install and it costs me time. Definitely a regression. I'd love a setting, even in dconf-editor, to keep the list fully expanded.

Another annoyance is that there is no way to keep the Details panel open across successive runs of the updater. Again, any kind of setting that would keep it open is welcome.

A note about that panel. Given that recent screens reduced the available vertical space, how about placing the Details panel to the right of the list of the updates? That would give more space to read them.