Updater lists many transitional dummy packages

Bug #1166230 reported by Steve Magoun on 2013-04-08
This bug affects 2 people
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Matthew Paul Thomas

Bug Description

update-manager 1:0.185, Ubuntu 13.04

The update-manager GUI lists a number of "Transitional dummy packages" available for update. There doesn't seem to be any additional information available about these packages through the UI. As a user I have no idea what I am supposed to do with them.

I suggest grouping the "transitional dummy package" under the "Ubuntu base" section in update-manager, so that they are not displayed to the end user by default.

To reproduce:
1) Run Software Updater from the dash
2) Look at the list of updates in the "Details of updates" list

The Ubuntu Software Center equivalent is bug 526330.

Steve Magoun (smagoun) wrote :
Changed in update-manager (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
assignee: nobody → Michael Terry (mterry)
Michael Terry (mterry) wrote :

I'll assign to mpt for suggestions, but I suspect he'll rightly say that this is really a bug with those packages, and you shouldn't blame the container for its contents.

Specifically, Debian policy says this about the one-line description synopsis: "Remember that in many situations the user may only see the synopsis line - make it as informative as you can. " Clearly "transitional dummy package" could not be described as informative.

Most of these transitional packages can be identified by "Section: oldlibs", so we could actually group them separately if we wanted to.

Changed in update-manager (Ubuntu):
assignee: Michael Terry (mterry) → Matthew Paul Thomas (mpt)
Matthew Paul Thomas (mpt) wrote :

Whether or not "transitional dummy package" is informative, that is what the Debian wiki currently recommends you use for the synopsis. <http://wiki.debian.org/Renaming_a_Package> And for all I know, maybe there are scripts or other tools for renaming a package, which embed that string in their code. If they exist, is it practical to change them to be more context-sensitive?

If not, then we have to reduce the visible redundancy ourselves. Two questions:
1. Why do transitional dummy packages need updates at all? What needs updating about an empty package?
2. The description of most of those packages says that it "can safely be removed". Why aren't we removing it instead of updating it?

Changed in update-manager (Ubuntu):
status: Triaged → Confirmed
Michael Terry (mterry) wrote :

Well, they are updated because their version number goes up with along with the related binary package. We theoretically should update it, in case the first version of such an oldlibs package didn't depend on exactly the right things or something. Seems unlikely, but we should do it.

We can't necessarily remove it because other packages are likely still depending on it. Until they are all cleaned up, we can't remove. At which point, it enters the "save to autoremove" list that apt-get generates. We might want to do something with those in update-manager, but that seems like a different bug.

We could say we will not show such updates, but silently update anyway. But we'd have to make sure the source was the Ubuntu archive, else malicious users could silently update packages. That would still solve most of the problem.

Matthew Paul Thomas (mpt) wrote :

Thanks for those answers. I'm thinking we should have a separate "Transitional packages" section below (not inside) "Ubuntu base". Does that seem sensible?

Matthew Paul Thomas (mpt) wrote :

But how do we tell that a package is a transitional dummy package, exactly? For example, ttf-arphic-uka and libdb4.8 are both in the "oldlibs" section. Both ship three files, or one if you don't count the changelog and the copyright notice. ttf-arphic-ukai is labelled "transitional dummy package", but libdb4.8 isn't.

Michael Terry (mterry) wrote :

Regarding a separate "Transitional" section, I'm not sure users would know what to do with that information. Maybe just throw them into "Ubuntu base" itself at that point, as they are similarly "implementation details" of how our packaging system works.

Regarding how to tell if a package is a dummy package, I can't find mention of any official or algorithmic meaning we can attach to "oldlibs". Maybe a combination of oldlibs+size could tell us if it is a "real" package.

description: updated
Scott Ritchie (scottritchie) wrote :

I endorse throwing it into ubuntu-base, which is code for "mysterious stuff you don't understand". I would also support just having a new "backwards compatibility" section to carry oldlibs.

As for why dummy packages exist, it's not just to handle old dependencies that haven't been updated. Sometimes apt's resolver needs a transitional package because it refuses to uninstall a package on a purported upgrade to that very package. So two upgrades have to happen:

wine1.4 (version 1.4-1) upgrades to dummy wine1.4 (version 1.6-2), which depends on real wine1.6.

One LTS release later, when I've removed wine1.4 from the archive and know that all wine1.4 are dummy packages, I can then have wine1.6 (version 1.6-2) which conflicts with wine1.4 and uninstalls it properly. One more LTS later I can remove those crufty bits from the metadata.

So, yes, a dummy package will thus linger for upwards of 2 years. Precise had wine1.4. Trusty will need a wine1.4 dummy package. 16.04 LTS can finally get rid of it using breaks/replaces. 18.04 LTS can avoid mentioning wine1.4 entirely.

Matthew Paul Thomas (mpt) wrote :

Thanks Scott for that lucid explanation. One more question (which applies to bug 526330 too): In Synaptic I count 105 packages in oldlibs. How many of those are *not* transitional packages? Are any of them packages that someone might reasonably want to install/uninstall (USC), or refrain from updating (Software Updater)?

Matthew Paul Thomas (mpt) wrote :

To try and answer my own question, these packages are in oldlibs in Ubuntu 13.10 and -- as far as I can tell -- are not transitional packages.

1. libdb4.8
2. libpangox-1.0-0
3. python-gobject-2
4. python-gobject-2-dev

5. i965-va-driver
6. kdegames-mahjongg-data
7. libdb1-compat
8. myspell-tools

So of the 105 packages in oldlibs, it seems that 97 of them are transitional packages and 8 of them are not. Is there a better Section those eight could be moved to? Or can they be excluded some other way?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers