Re: dpkg modification: non-interactivity
"Jesus M. Gonzalez" <jgb@gsyc.inf.uc3m.es> writes:
> Mitch Blevins writes:
> > Wichert Akkerman wrote:
> > > Previously Jesus M. Gonzalez wrote:
> > > > On another topic, I'm also worried by the instalation of
> > > > machines sharing disks (via NFS or CODA). In that cases, you can share
> > > > a single /usr, for instance, for many machines.
> > >
> > > That is completely orthogonal to the configuration issue, but what dpkg
> > > needs is a configuration which tells it to ignore certain parts of the
> > > filesystem. You can then install a package and have dpkg not install
> > > stuff in /usr/doc, or skip /usr/bin, /usr/sbin and /usr/X11R6, etc.
> >
> > YES!
> > My thoughts exactly. I'd like to see more discussion on this.
> >
>
> I agree on the orthogonality. The solution you propose
> (configuring dpkg so that it just ignores some directories) sounds
> good. Another approach could be to check every file before installing
> it, and not even try to install if the file is already present (and is
> like the one to be installed, via a checksum, for instance). This
> could have the extra benefit of not leaving half-installed packages if
> you forget to install them in the server...
>
> Jesus.
That won't work with files that are changed by the install
scripts. When unpacking the file would differ and thus dpkg would try
to overwrite the servers file, which is probably read-only. Later the
script would try to change it, so it would try to write again.
libtricks is the answere to the problem. Any attempt to modify a
shared dir should be redirected to /tmp and after the installation all
the files and directories that went to /tmp could be checked against
whats on the shared directory. Any difference means a problem and
calls the administrator for help.
May the Source be with you.
Goswin
Reply to: