Related but WAS: [PATCH 0/6] patch series for review: conffile database + merging
- To: Sean Finney <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Related but WAS: [PATCH 0/6] patch series for review: conffile database + merging
- From: Goswin von Brederlow <email@example.com>
- Date: Mon, 05 Oct 2009 13:32:49 +0200
- Message-id: <firstname.lastname@example.org>
- In-reply-to: <email@example.com> (Sean Finney's message of "Mon, 28 Sep 2009 23:34:27 +0200")
- References: <firstname.lastname@example.org>
Sean Finney <email@example.com> writes:
> the following series of patches is a renewed attempt at conffile tracking,
> where the packaged conffiles are stored in a seperate location on the
> system in their pristine forms. the patches the follow contain more
> information on the details.
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:
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.
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
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.
What do you think?
PS: ucf would have to plug into theat API too.