Bug#695764: partial review of unblock: packagekit/0.7.6-2

[Matthias Klumpp <matthias@tenstral.net>]

Hi!

2012/12/28 Paul Gevers <elbrus@debian.org>:
> [...]
> Some remarks:
> - The package is in unstable now.
> - The debdiff in the first message is the same as created from the
> archive by "debdiff packagekit_0.7.6-1.dsc packagekit_0.7.6-2.dsc"
> - It would be good to mention bug numbers against packagekit and/or
> references to the upstream bug tracker. I/we don't know where to find
> the information trivially, making the assessment harder than necessary.
Okay, here we go:
patch_01: http://gitorious.org/packagekit/packagekit/commit/bc4b83118a95c8524dedd845d86c28ad5b810483
patch_02: http://gitorious.org/packagekit/packagekit/commit/c3eed50835846b0357693cceb1d4654713c30e94
patch_03: http://gitorious.org/packagekit/packagekit/commit/7bf5a007a97344390c49dbf6843d209d0edb4dc9
These links point to the 0.7.x branch of PackageKit upstream, Please
note that some patches have been modified to be smaller in Debian.
(e.g. killing whitespace removals)

> Isn't patch 03 fixing bug 688133?
No, but a partial bugfix. A sane solution would be if apt-get emitted
SuggestDaemonQuit() to PackageKit via DBus and would print a sane
error message if the daemon does not quit in a few seconds. Running
apt-get while the transaction daemon is working (and locking the
archive) does obviously not work.
What this fix does is to close the archive lock faster, so users won't
see this issue very often. (before, PK sometimes left the cache open
until the daemon timed out, which was very bad behaviour)

> - It would be nice (for next time maybe, or just in this bug) to store
> the URL of where the patches were obtained, see DEP3 [2]
Yep, agreed - but I extracted them directly from our Git repo, so they
contain the original Git hashes, which allows identifying the original
commits too. (but urls are nicer)

> - Patch 01 looks ok
> - My C/C++ is not good enough to really follow patches 02 and 03, but 02
>  contains a spurious empty line removal.
I promise that this won't change how the code works ;-) (I probably
overlooked it)
> [...]

2012/12/30 intrigeri <intrigeri@debian.org>:
> [...]
> Matthias Klumpp wrote (12 Dec 2012 12:47:07 GMT) :
>> +packagekit (0.7.6-2) unstable; urgency=low
> [...]
>> +  * Removed some unused build dependencies
>
> I'm not sure the build dependencies changes qualify for an unblock
> request at this stage of the freeze: they may change the produced code
> in ways that are hard / impossible to review. Do these changes fix
> actual problems? (Bonus points if bug numbers are provided :)
The build-dependency-removal does not qualify an unblock, the included
patches do. The removed dependencies only make building faster. They
were legacy dependencies from the very old PK 0.4.x series and haven't
had any influence on the resulting binary. The dependencies have been
killed on Ubuntu for a long time already and are also gone with
PackageKit 0.8.x for Debian (which is currently available in
Experimental)

> I don't feel able to review the C++ code changes, so I've no clear
> position on this request anyway, but I guess the Release Team might
> feel more comfortable with this request if they are pointed to bug
> reports the proposed update fixes.
The patches fix some very hard to track issues with PackageKit-Aptcc
which some users noticed and which became obvious during the
development of PK 0.8.x and Apper 0.8.0, since we now understand Apt
much better.
I can point you to some Ubuntu bugs about this (Debian currently has none).
Basically, the current Aptcc in Testing does:
 * mark packages as auto-installed which clearly weren't
auto-installed, and therefore creating an inconsistent package
database
 * give wrong information about which packages are trusted and which
aren't, which might confuse users
 * locks the cache for a long time, which prevents other tools like
Synaptic or apt-get from working until the PK daemon times out.

Given that PK is default for many Debian flavours and therefore many
users are affected by these annoyances, it would be good to fix them
as soon as possible.

Cheers and happy new year!
    Matthias