"Christian Goetze (CG Linden)" <c...@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
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
