ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

click 0.4.4 at last supports removing Click packages via a new "click
unregister" command and wiring up the
org.freedesktop.PackageKit.Transaction.RemovePackages interface.  This
should be enough for UI folks to get going on their end of things, but
there are a few gotchas which I'll note here.

 * I've generally tried to autoremove packages when it makes sense (e.g.
   superseded by newer version, no user registrations, not running,
   etc.).  However, because I made the mistake of not having user
   registrations there from the start and not making them mandatory,
   it's possible that people have installed packages with no user
   registrations that look like they ought to be garbage-collected.
   This is probably something I need to clean up as such packages are
   not really very useful (no ~/.local/share/applications/ links, etc.),
   but for the meantime I've just arranged for them not to be GCed.

 * There's a dynamic "_removable" key in "click list --manifest" which
   tells you whether a package can be removed.  At the moment this is
   true if and only if the package was user-installed in the last
   database in the list, i.e. /opt/click.ubuntu.com.  This may change;
   it's possible to have more than one database in a read/write
   location, and I plan to add "whiteout" support so that a user can say
   they don't want to see a preinstalled package any more even though
   they can't actually remove it from disk as such.  UIs shouldn't worry
   about the details of this, and should just offer the "remove" option
   for those packages with "_removable": 1.

 * The PackageKit RemovePackages interface is a little awkward in terms
   of what people have been doing so far, because you need to pass it
   PackageKit IDs.  These are of this form:

     com.ubuntu.test;1.3;all;local:click

   If the fourth ("data") part of the semicolon-separated ID isn't
   "local:click" then the Click plugin won't know that it needs to
   handle removing the package rather than passing it through to the
   next backend, so do make sure you include this.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]