Apt's unable to acquire lock message isn't user friendly

I just realized I should explain this a bit more. The error message does ask if another process is using the lock, but this could be better explained. Here's a proposal for what it could say instead, that would be much much more useful:

"Apt was unable to lock the package database. This means that either you don't have permission to install/remove packages (check that you are root or are using sudo), or that another program is currently using the database. If you have Adept, Synaptic, or Add/Remove Programs, or another instance of Apt open, you must close them before using apt.

If you are absolutely sure that no program is currently using that database, it is possible that a program crashed while using the database. To remove this program's lock on the database, delete the file /var/lib/dpkg/lock."

This is a lot less likely to confuse and informs the user of their options.

I've attached a screenshot of the very confusing dialog I get when two instances of apt are running simultaneously. The dialog states:

"Another synaptic is running"
"There is another synaptic running in interactive mode. Please close it first."

To cause this dialog to appear, I opened Update Manager and Software Sources at the same time. Neither of these programs is named "synaptic" as far as the user is aware. What is synaptic? Why do I need to close it? How do I know which application this is referring to?

How about the following alternative dialog in Software Sources, when Update Manager is holding the apt lock:

"Could not update software sources"
"Software sources could not be refreshed because Update Manager is accessing the same information. Please close Update Manager first."

How about apt-get sense that synaptic or adept is running and say so? I mean, if you are going to refer to specific package managers in your error output, you might as well sense for them as well.

Eg:
apt-get was unable to complete the operation you requested, because there is another package manager running. Please close "Synaptic Package Manager" and try again.

The program tha acquires the lock could probably write a human-readable name as meta-information on the lock file itself, so other instances could use that on their error messages.

Consider probable situation when e.g. Synaptic was not closed properly and it left lock in that directory. I don't know how this should be treated - "$program was unable to [...]etc. etc. If there is Synaptic opened, maybe you should delete the file '/var/lib/dpkg/lock'?" Doesn't that sound weird for an non-technical user?

Thinking about this a little more -- perhaps the problem is also the method of locking. Users wouldn't get this error message half the time in the first place if the lock was cleaned up when apt/synaptic/etc crashed, not just when it exited normally.

It would be nice if dpkg, apt et al. waited for the lock indefinitely instead of bailing out immediately. The UI could show a throbber and a caption such as “Automatic security updates are being installed. Please wait.” or whatever is appropriate for the piece of software holding the lock.

@David Siegel : *You should change this to milestone 10* , wait for mpt to finish work on the new AppCentre[which replaces Synaptic] and then set a milestone. Else it would mean working twice on this papercut.

This bug describes a different issue (apt's command-line UI), and we're not sure that this issue will be exposed in Karmic.

The paper cut task was originally closed because the offending string wasn't believed to be exposed in the UI. Is this still the case?