Re: Module proposal: dconf [migration from gconf]



On Fri, 2009-10-23 at 12:48 +0200, Alexander Larsson wrote:
> On Fri, 2009-10-23 at 10:53 +0200, Josselin Mouette wrote:
> > Le jeudi 22 octobre 2009 à 14:48 +0200, Alexander Larsson a écrit : 
> 
> > > So, I say, leave old apps using gconf alone, and leave the gconf storage
> > > alone too. It works (to some degree) and will continue to work (to the
> > > same degree) in the future with minimal maintainance.
> > 
> > That means keeping on maintaining GConf for quite a long time. For the
> > record, it took us around 8 years to get rid of GTK+ 1.2. GConf is not
> > as widespread, but it is already ~600 packages. From the moment
> > GSettings is widely deployed, I’d expect at least 3-4 years before being
> > able to not install it by default on Linux systems; in the meantime,
> > this means starting both daemons in user serssions. And 5-6 years before
> > being able to get completely rid of it.
> 
> It would only need to be installed if some app you install requires it,
> and it would only run in the session if some app actually runs that uses
> it. (Assuming we patch it to exit if the last client connected to it
> exits, which I'm not sure happens today.)
> 
> > This plan is clearly less work right now, but it means more maintenance
> > work in the long term.
> 
> How can you be sure of that? Any other plan involves first writing and
> debugging a new set of software to support the gconf api on something
> else, then maintaining it for as long as we would have to maintain
> gconf, and this being new software it is likely going to be more work to
> maintain.

I think Josselin is talking with his distro maintainer hat on (not as a
software maintainer): having to keep GTK+1.2 libs around for so long was
a pain.

	Xav





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]