[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