Moin,

On Sun, 16 Dec 2018, 16:02:20 +0100, Maurizio Galli wrote:
> > Something like that, maybe with moving stuff into a backup location
> > instead of deleting it
> 
> Yes should be easy enough to do with something like: mv
> ~/.config/xfce4/xfconf ~/xfconf.bak
> Open to better suggestions.

Don't move it across potential mount boundaries, please. I use
directories like ~/.config (and others) as bind mounts to
~/.OS/os15.0/.config (etc.) in order to protect against such
incompatible changes (KDE told me a lot in this regard...); so, please
move it to ~/.config/xfce4/xfconf.bak, if ever.

> >  (I'm not sure how good other parts cope with xfconfd going away)
> 
> To be confirmed, but having xfconfd killed / not running,  seems to be
> a necessary step to correctly regenerate the config files. Also
> xfconfd is restarted as soon as xfce4-panel is reloaded and personally
> I did not experience side effects although I cannot completely exclude
> that.
> 
> > and with some nice popup window asking to confirm ;-)
> I am not  good at this stuff but I will wrap my head around it to find
> a way ;-). Should we include this script in the panel package or
> branding package?

Perhaps a test if a user is running XFCE while these updates should be
pulled in would be appropriate. E.g. kernel packages request an explicit
confirmation for installation because a reboot would be in place;
something in this area might me applicable here, too.

> I don't  know how long I need to get this one ready but I think I
> should push the update to Factory ASAP first, or more people will
> update and risk to mess up their configs.
> 
> Cheers,
> 
> 
> Maurizio Galli (MauG)

Cheers.

l8er
manfred

Attachment: signature.asc
Description: PGP signature

Reply via email to