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

Re: Related but WAS: [PATCH 0/6] patch series for review: conffile database + merging


On Mon, Oct 05, 2009 at 01:32:49PM +0200, Goswin von Brederlow wrote:
> in a recent discussion on irc we pondered the possibility of
> maintaining /etc in an RCS (git in that case). Two ideas then came up:

i think there's a few solutions that come close to this already (etcgit
being one off the top of my head).  i think that keeping it closer to
the package manager would be better though, so use of aptitude/synaptic
wouldn't result in missing some commits.

> 1) commit changes per package
> Every time a package is installed or removed it would be nice to
> commit those changes automatically. Idealy on a per package basis but
> we recognised that sometimes dpkg needs to install packages in groups.

it wouldn't be too hard to expose some kind of per-package hook for
the first use case, and through use of triggers it would be possible
to catch the second use case.  this would allow for a commit+tag on a
per-package basis and a second tag for batches of changes.

> 2) merging using the RCS capabilities
> Using a normal RCS workflow one would keep the original conffiles in
> an upstream branch and merge that with the working directory / local
> branch. To make this feasable and usefull it would be nice if the dpkg
> conffile handling could be made aware of this so it unpacks the
> conffiles into an upstream branch and merges instead of the current
> way.

this sounds a bit scary imo, because it travels pretty far out from the
safe confines of dpkg and into a fairly complex and relatively unstable

> Both could be made to work if dpkg had hooks at the right places. It
> could even be made possible for users to replace the conffile tracking
> in this patch series with git or mercurial or other RCS of their
> choice. Maybe there should be an API for conffile tracking and merging
> and different RCSes could provide wrappers for the API while dpkg
> provides a default.

i'd prefer to leave any such implementation as a follow-up to this initial
effort, as the current code is relatively simple and streamlined and in
no way closes the door for future work.



Attachment: signature.asc
Description: Digital signature

Reply to: