Re: Merging Admin Dirs?

[Goswin von Brederlow <goswin-v-b@web.de>]

"Christian Goetze (CG Linden)" <cg@lindenlab.com> writes:

> Apologies in advance if this is the inappropriate list, please feel free
> to refer me to a better place.
>
> I am aware that there is a dpkg --admindir=<someplace> option, and I
> wish to use it for doing installs "on top" of a canned debian install.
> The idea is to allow two separate groups of maintainers to control what
> is installed on a specific box: the core group which produces the base
> install, and an application group which adds rapidly changing versions
> of applications on top of the core install.
>
> I wished there was a way to specify multiple admindirs, only one of
> which is used to write the new information, but all of them are used to
> resolve dependencies. My current choices seem to be:
>
>     * Use --admindir on an initially empty directory, and don't check
>       for system dependencies, assume they are OK - one can do a dry run
>       install without --admindir to verify that these are satisfied
>     * Use --admindir on a directory that contains a copy of the "core"
>       admin dir. This will work until the core is updated, after which
>       there is no way to go anymore.
>     * Don't use --admindir, share the system dir. This would require
>       changing the way our core group maintains our server farm -
>       currently maintained via rdist...
>
> Ideas?
> --
> cg

How do you prevent the application group to uninstall or upgrade one
of the core packages?

Here is an idea:

* Wrap dpkg and dpkg-divert. Before starting you cat the core and
  application data into a working copy. After dpkg/dpkg-divert you
  remove the core part from thw working copy and store it as new
  application data.

You could use something as simple as patch/diff for the status files,
git or write something specific to your case.

MfG
        Goswin