On Sun, 2011-07-10 at 13:25 +0200, Josselin Mouette wrote: > Certainly not as is, since it would satisfy dependencies immediately for > all packages that should get dconf installed instead.
That is exactly what I desire. dconf isn't friendly to ~/ in git since configuration details are stored in one big binary blob so I don't want it installed or used or anywhere near any of my systems. > Maybe by splitting the backend in a separate package. And even this way, > it needs to be enabled by hand so I’m not sure it’s the best course of > action. The GConf GSettings backend is not really well supported > upstream, and the most likely result is that people have broken settings > and don’t understand how. Splitting it out would be acceptable. I can probably inject a GSETTINGS_BACKEND=gconf environment variable somewhere to enable it. -- bye, pabs http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
