Re: dpkg modification: non-interactivity
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
Reply to: