[packagekit] PackageKit & Debian, Was: External dependencies, DeviceKit-power and GNOME Power Manager

[Josselin Mouette]

Le mercredi 26 novembre 2008 à 11:25 +0000, Richard Hughes a écrit :
> On Tue, 2008-11-25 at 23:26 +0100, Josselin Mouette wrote:
> > To sum up, the main concern that I have heard from most interested
> > Debian developers about PK is its lack of support for debconf. If PK was
> > able to answer to queries from a DBus-based debconf frontend to show the
> > questions, everything else would be a matter of fixing our tools and a
> > few broken packages, and of course to improve the backend.
> 
> A DBus based frontend to show questions smells very much like an
> out-of-band transaction, which I would argue should be done in the
> existing transaction framework.

By "frontend" I meant a frontend on the debconf side. It should of
course integrate in the existing framework for communicating with the
upper layers.

> There's more details about transactions here:
> http://www.packagekit.org/gtk-doc/introduction-ideas-transactions.html

> > From previous discussions, I understood that you were not willing to
> > accept patches that would add support for querying the user. If your
> > mind has evolved on this topic, that would certainly encourage some of
> > us to code it.
> 
> Sure, have a look at the link above. If you read what I said in context,
> you'll see that I'm refusing to block the transaction and wait in that
> state for user input. It's perfectly okay if the transaction is stopped,
> and then the user can answer questions and requeue without blocking
> other transactions for all the other users on the system.

I don’t think it is possible to achieve this for all cases.

A typical APT/dpkg session can be decomposed in the following phases:
     1. download
     2. preconfigure
     3. preinst+unpack
     4. postinst

The target moment for invoking debconf is clearly phase #2. This is done
by running the $package.config scripts in a sequence. Each script will
pass questions to the debconf frontend with INPUT commands, and will ask
for showing them with the GO command. The script will then be able to
receive the answers with GET commands, and if appropriate will ask other
questions. Of course, most packages don’t do complicated things and just
ask 1 or 2 questions with a low priority, but the protocol allows much
more.

To make things more complicated, questions can also be asked in phase
#3. Here, they are meant for things about to seriously break and that
require some kind of confirmation. They can also appear in phase #4,
mostly about configuration file modifications.

While being the most common, phase #2 is not the most important one to
implement, although that’s nice to have. However, from what I understand
of the current requirements in PackageKit, none of the phases are
possible to implement, since they all wait for replies from the
frontend.


It would certainly be nice to modify the debconf specification to allow
for transactions: config scripts would be forbidden to get answers; they
would access the list of modified configuration files to ask earlier
what to do with them; prerm scripts could access answers of questions
from the config scripts; postinst would not be allowed to ask questions.
As a long-term goal, it makes a lot of sense, but there are a lot of
challenges to solve to make it happen, especially to make it happen
without breaking existing packages (not talking about implementing stuff
like ucf in a transactional way).

However, such important distribution-wide changes are not going to
happen if people don’t see first the benefits. If we can have a working
PK that gets everyone’s attention because it works nicely, it will
become a target that will justify more important changes. On the
contrary, if it is so restricted that we cannot enable it by default, we
can just forget about that.

> > And to make things clear, the intent is certainly not to flood the user
> > with questions he won’t understand. We continuously hunt abuse of
> > debconf and remove or lessen the priority of annoying questions.
> 
> What sort of questions do you want to ask the user? Will any of these
> people http://www.packagekit.org/pk-profiles.html know what the answers
> should be?

Graham probably doesn’t need PackageKit on Debian (unattended-upgrades
will do the work without scaring him), and Suzan is not likely to run in
any case that will require her to reply a question, so let’s forget
about them.

However, I think Bevan is someone who will run into trouble without
this. Bevan is probably running Debian testing or unstable. He likes to
tweak his systems, and often finds some tutorials on the web that will
include modifications to configuration files or installing packages from
custom sources.

When, later, a package that Bevan has configured is upgraded, the
configuration file he modified is about to be upgraded as well. In some
cases, installing the new version will break something he is now relying
on, especially if it interacts with other packages. In some other cases,
keeping the modified version will make the package fail to work as
expected. If, instead, Bevan sees a question about a modified
configuration file, he will remind of his change, and will have a wild
guess about what to do. The same reasoning holds for the case where
Bevan has installed a custom kernel image from the web to support some
specific hardware, when udev gets upgraded in a way that will make this
kernel fail.


That said, I think it is very restrictive to limit the scope of a tool
to a set of imaginary users. GNOME has always been about providing
simple and powerful tools for everyone, not for some classes of users.
If the tool is better for Suzan, it should also be better for me. If, as
the package’s maintainer, I can’t use it, I fail to see how I could
improve it for our users or help them with bug reports. I could only
imagine what their requirements are and would remain disconnected from
their reality.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20081126/77e0fadf/attachment-0004.pgp>