Armed with a text editor

Inplace Tooltips vs. Aptitude Posted 2008.02.06 20:42 PST (#)

A long time ago I started work to port my rudimentary treeview hack from its TreeViewHints python implementation in Quod Libet to a much more solid inplace-tooltips implementation in gtk+ itself. Inplace-tooltips are the little tips that appear as you move your cursor over items that aren't fully visible, and often appear immediately instead of after a hover delay.

For whatever reasons the patch has neither been nurtured and accepted nor denied, and has languished for most of the 19 months since I first filed the feature request. I personally suspect things varying from confusion over the term tooltips being in the name to malevolent negligence, but claiming either of those doesn't help the situation anyway.

Eight months ago I found a much better approach to it, which wrangled out some superficial bugs for free, and updated the patch. Finally over the past two weeks, I found that Debian's gtk+ package had changed its build procedure, and this time was able to figure out how to integrate my patch. Wow, what a difference it makes to use it full time. In under two weeks I'd found and filled some important gaps in my initial implementations, including fixing the tip's position when a tree is scrolled horizontally.

But building my own Debian packages comes at a price. Not only does it take significant time to build the packages, there are three options each with disadvantages.

• Apply just the code patch

By applying just the code patch I get all the behavior changes I want...so long as I don't run a package update. If I run a package update, the original libgtk2.0-0 package takes precedence over my package, and offers to reinstall.

• Also apply a debian revision suffix

When Ubuntu makes packages, they apply a suffix to ensure that Debian's packages of the same version do not override theirs, but a newer Debian package can (so long as all dependencies are satisfied). This prevents the official package from overwriting my patched packages. However doing this causes the policy of my package to move past the testing archive and into the limbo which pulls in packages from unstable. It also requires I install some auxiliary packages due to tight version dependencies in the core gtk+ related packages.

• Apply an epoch

An epoch is a special version indication that would let me continue to call my package by the same version the rest of gtk+ does, but tell the package management system it's newer than the official package. Assuming Debian never needs to bump their epoch, this would insulate me from the testing–>unstable bump, as my packages would always be even newer than the ones in unstable. However because of that it would be much harder to track when it was time to upgrade my own packages.

Currently I gave up on the first, and am still trying the second. I've run into one major hitch: aptitude doesn't work how I want it to. In particular I'm running with my suffixed package version 2.12.5-2+0mu, and unstable now has 2.12.7-1:

% apt-cache policy libgtk2.0-0
libgtk2.0-0:
  Installed: 2.12.5-2+0mu
  Candidate: 2.12.7-1
  Version table:
     2.12.7-1 0
        601 http://http.us.debian.org unstable/main Packages
 *** 2.12.5-2+0mu 0
        100 /var/lib/dpkg/status
     2.12.5-2 0
        900 http://http.us.debian.org testing/main Packages

Because I'm beyond testing (which I have as my default), apt and aptitude want to attempt to keep me at unstable (my fallback) because it appears that's where I was before the update. I'm not ready to make this leap; I want to make it when 2.12.7 reaches testing. So I employ the next trick in the book: hold.

Hold is supposed to tell aptitude to ignore this package during normal upgrades until I explicitly tell it to install a newer version. But it just doesn't work. If you visit aptitude's bug page and search for hold it becomes obvious that there have been lots of problems with hold, and most of them are still unresolved. Most of them have to do with synchronizing aptitude's list of holds with dselect (and apt's) list. But if that were all, I could work around it. Instead aptitude doesn't even follow its own holds:

% dpkg --get-selections | egrep 'gtk2-engines-pixbuf|libgtk2.0-0|libgtk2.0-dev'
gtk2-engines-pixbuf				hold
libgtk2.0-0					hold
libgtk2.0-dev					hold
% sudo aptitude unhold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev
[...]
% sudo aptitude hold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev  
[...]
% sudo aptitude safe-upgrade
[...]
The following packages will be upgraded:
  gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev 
3 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 6061kB of archives. After unpacking 12.3kB will be used.
Do you want to continue? [Y/n/?] n
Abort.

Now that I've seen this sloppy behavior among others, and seen just how many long standing bugs there are against aptitude, I think it's time to go back to dselect, apt-get, and deborphan. Too bad; aptitude seemed like a good idea at the time.