Re: Related but WAS: [PATCH 0/6] patch series for review: conffile database + merging
Sean Finney <seanius@debian.org> writes:
> hi,
>
> 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.
Yes. But the best they can do is do a commit per apt invokation,
which is usualy for a ton of packages at a time. Even if apt where
more fine grained it would be per dpkg invokation, still a lot of
packages.
One could probably try to detect which file belongs to which package
and commit them first, then commit anything not belonging to anyone.
Not optimal.
>> 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.
The hook could be triggered for a set of packages and as frequently as
possible. The packages and old/new version could be given as command
line arg or stdin. Maybe even a file list on stdin in the form "<pkg>
<file>\000"?
If 2 packages must be installed together then commiting the changes
together isn't the end of the world. It should just be more frequently
than a "apt-get dist-upgrade" call.
>> 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
> system.
The simplest implementation could just add another option to the dpkg
menu to call an external hook. The hook would get the current, new
orig, old orig files as argument and do its magic. Alternatively just
the current filename and the dpkg-conffile interface to retrieve
new/old orig itself. It could be moving the new orig into an upstream
branch and merge or it could call vimdiff or whatever the user chooses
to use as hook.
The important part would be to define a stable API, give access to the
new/old orig conffile and current file and define return codes for all
ok (0), back to the menu (100) and error (any other) or something.
Doesn't need to be a complicated implementation. And use at your own
risk. :)
>> 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.
>
>
> sean
Fair enough. Just keep it in mind you don't design something that
later blocks it.
MfG
Goswin
PS: thanks for the effort, this is wanted a lot
Reply to: