[packagekit] New signal for configuration file update

Mounir Lamouri mounir.lamouri at gmail.com
Thu Jul 30 15:15:15 PDT 2009


Richard Hughes wrote:
> 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");

About the suggestions, as we should call the distribution tool, it will mostly
be up to this tool. I think we should avoid suggestion or move to something
like: ENUM_SUGGEST_TOOL, ENUM_SUGGEST_IGNORE, ENUM_SUGGEST_NONE

Ok for the lest of file names.

For the package, I think it's quite difficult because the update can result of
an multiple installation of packages or even of a dep of an installation and a
list of updated files can be related to more than one packages.
I see two solutions: we accept the list of packages and we will not know which
file is linked with which package or we do not emit package and we consider the
client will use the search_files to know at which package is the file (if needed).

I'm not sure the last string (description) is used. If you think it is possible
a backend will have different reasons to do conf update, I think we can add an
ENUM for the update type like UPDATE_TYPES of package signal for get_updates. It
could probably replace suggestion.

Last but not least, we should probably add the path to the merging tool.

So, it will be:
configuration-file-updated:
 suggest,
 (and/or)
 type,
 paths,
 packages?,
 tool_path

Thanks,
Mounir



More information about the PackageKit mailing list