[packagekit] New signal for configuration file update

[Richard Hughes]

2009/7/28 Mounir Lamouri <mounir.lamouri at gmail.com>:
> For Gentoo/portage backend, I need a new signal about updated configuration
> file. Indeed, Gentoo/portage has a protected file management which are
> (mostly/only) configuration files.
> If a package is updated and tries to overwrite a configuration file, the new
> file is copied and the old one is kept until the user explicitly chooses to
> update the file.

Sure sounds sane. We do the same with .rpmnew files with yum.

> So, I need a new signal to inform about these updates. It's actually really
> simple. Here is a brief idea in python:
> def configuration_file_updated(self, path):
>  print "configuration-file-updated\t%s" % path
>
> It's quite easy because we only need the path.

Right, but I don't think the path is enough -- we should be able to
tell the frontend what the repercussions of this is -- so we need to
pass down a type of event, and what the tool should suggest, and the
package update that caused it at least, and probably some notes about
what the user should do, sortof like the error details.

So, something like this:

::UserInteraction(u=ENUM_CONF_FILE_UPDATED, u=ENUM_SUGGEST_MERGE,
s="/etc/X11/xorg.conf;/etc/X11/xorg.conf.new",
s="xorg-server;1.2;i386;updates", s="package update requires
configuration merge");

or something like that. It has to be more generic than "here's a
filename, deal with it"

> Actually, this signal is mostly to say a configuration file has been updated
> because clients API needs to know that. The path is much more for user
> information because, (at least for portage) distro tools will check for updated
> files by themselves.
> Clients API usage of this signal will be for another thread.

Well, I think it makes sense to pass enough data to the client to make
it useful.

> Richard, will you want to see the patch before I commit ?

We need to decide on the signal format first -- adding public API is a
big task and not something you want to do twice :-).

Richard.