[packagekit] New signal for configuration file update

[Daniel Nicoletti]

Hi, this was the next step I'd like to do
when simulate is done, we also have this behavior in Debian,
but we prefer to keep the old one installed.
Now that this is being handled by someone else let me tell
what I was thinking...

confFilesUpdated(USER_KEPT | UPDATED, file list)
updateConfFiles(KEEP_USER | UPDATE, fileList);

Then we can show the user an UI like this:

The following configuration files "were updated" |
"have a new version":
FILES:                                       "Keep current" | "Update"
/etc/apache2/apache.conf       [   ]
/etc/squid/squid.conf                [   ]

* You distribution has already chosen the safest option,
if don't know why they appeared here, just leave this
dialog as it is.

[ Change ] [ Cancel ]



Daniel.





----- Mensagem original ----
> De: Richard Hughes <hughsient at gmail.com>
> Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
> Enviadas: Terça-feira, 28 de Julho de 2009 18:53:34
> Assunto: Re: [packagekit] New signal for configuration file update
> 
> 2009/7/28 Mounir Lamouri :
> > 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.
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit



      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com