Re: dpkg modification: non-interactivity
Mitch Blevins <mblevin@debian.org> writes:
> Wichert Akkerman wrote:
> > Previously Mitch Blevins wrote:
> > > My thoughts exactly. I'd like to see more discussion on this.
> >
> > I'm not sure exactly what kind of discussion you would like. The minimal
> > implementation is a file with a list of directories dpkg should ignore.
>
> I guess it seemed so easy to implement that I was wondering why we
> didn't already have this capability.
> But you proved me wrong (below).
>
> > This can and will break any application that does not follow policy and
> > tries to modify something in /usr of that is shared. Another thing is
> > {pre,post}{inst,rm} scripts trying to modify things in a shared
> > directory, which is clearly also bad. And finally things like
> > update-alternative, install-info, and dpkg-divert will need to honour
> > exclusions.
> >
> > We can fix it quite easily for dpkg, dpkg-divert, install-update,
> > update-alternatives. Modifying the {pre,post}{inst,rm} scripts will be
> > hell, and everything else it outside our control.
>
> I hadn't thought of the pre/post/etc scripts.
> That would be damn near impossible to fully implement in any reasonable
> amount of time.
> Maybe we could use something similar to libtricks where dpkg (and spawned
> programs like the post/pre scripts) are presented with a 'fake' filesystem
> that appears to change for them, but is only an illusion.
> <insert Doug Henning hand gesture>
>
> This would require minimal changes to dpkg and no changes to the scripts.
> Anybody see problems with this?
>
> -Mitch
Telling libtricks to ignore any changes to /usr (or whatever is
shared) should be enough. Any atempt to change something in /usr
(e.g. write a file there or delete something) would just come back
with a success as return value but not do anything.
When dpkg is started with such a libtricks config, the prerm, postrm,
preinst, postinst, ... scripts will all leave /usr unchanged.
May the Source be with you.
Goswin
Reply to: