Re: [gentoo-dev] Portage config auto-update

[Matt Tucker]

-- Joseph Carter <knghtbrd@×××.org> spake thusly:

> Very cool. This is almost enough to actually use CVS for files in
> /etc, or at least RCS.
I actually briefly considered using CVS (several other people have
mentioned it, and I actually use CVS myself to maintain config files),
but discarded the idea because it didn't seem necessary. However, I'd
be willing to reconsider it if there's a strong demand for it. In that
light, I'll answer a bit of what you had to say.


> The reason why RCS might be needed instead of CVS is illustrated
> using file:
<snip>
> Note that CVS is not fond of symlinks, but tollerates them as long as
> they are not in the CVS database.  Suggest two trivial functions to
> manage this: one which prunes nonexistant files from .cvsignore, and
> one which ensures that any symlinks get listed.

Symlinks could also be handled by doing a little shuffle behind the
scenes before bringing CVS into the picture. If a symlink is
encountered that needs to be committed, updated, etc, simply move it
out of the way temporarily, put the destination in it's place, invoke
CVS, then move everything back. This would be a pain for a user to do
each time, but it's no problem for a script.


> CVS does not gracefully cope with binary data.  Obviously certain
> files here are generated automatically and would also get
> .cvsignore'd.  ELF binaries have absolutely zero place in /etc,
> according to the FHS, however.

Sure they don't belong there, but it happens anyway.

I think CVS copes with them well enough; it'll store the things, but
refuse to merge them. But I don't attempt to merge binaries either
(what would be the point)? I think it would still make sense to keep
the original around for comparison, just as I'm doing now.


> RCS would allow config file management without dealing with these
> issues since you'd only maintain RCS files for those things you
> actually care about.  I would consider this more a bandaid though, I
> would prefer that etc-update have a config option to maintain
> .cvsignore files for you so that your CONFIG_PROTECT directories may
> trivially be stored in CVS, using a helper tool which a sysadmin can
> use themselves if they like.  In this way, etc-update would merge
> changes into a temp file, let you edit it, and then overwrite your
> existing file as an atomic operation.  When you're done, check the
> results into CVS for safe-keeping.
>
> CVS vendor tags are also an option, however they are more complex to
> work with in my experience and fewer people will be able to do it
> well.  Doing the merge into the working copy in the CONFIG_PROTECT'd
> directory is probably easier for people.  If the files are also
> checked in with a vendor tag, that'll just make it easier for tools
> an sysadmins which grok more advanced CVS usage.

That makes perfect sense, actually. If the file is modified, bring the
new config versions in on a branch with a vendor tag, and then merge
back into the trunk.


> I haven't yet looked over your patch extensively (and do not trust
> myself to not screw something up at this hour), but I figured I'd
> offer my comments anyway.  Take them with a Syberian salt mine if
> they seem to be missing something obvious.  =)

Thanks for your comments. As I said, I'll definitely look at revisiting
the CVS idea if there's demand for it. If we end up doing it, it'll be
made easier by having the config_protect handling broken out the way it
is now.



--
gentoo-dev@g.o mailing list