Re: Packaging system improvements
> > ------------------------------------------------
> > delete /usr/doc/
> > check /usr/doc/
> > verify /usr/doc/
> > replace /usr/man/ /usr/share/man/
> > backup /usr/share/ /usr/local/share/
> > ------------------------------------------------
> >
> > The first line ("delete") means that files normally installed in /usr/doc
> > should be omitted.
> >
> > The second line ("check") means that files normally installed in /usr/doc
> > should be omitted, but to make sure that those files already exist under
> > /usr/doc (this may be a network mounted drive managed by another computer).
> >
> > The third line ("verify") is just like a "check" except it also verifies
> > that the files are the same using the equivalent of diff(1).
>
> ... and if the { check, verify } tests fail, do what? Two possible
> alternatives would be (1) to abort the installation of that package
> (requiring manual action to deal with the problem) or (2) install
> the files which would otherwise have been omitted (which might be
> appropriate, or might not).
If it fails, then the package won't install. Installing files which might
otherwise have been omitted won't do anything because no package in supposed
to duplicate the files of another anyway. Thus, for any of these rules
to be in place, there must have been a reason; most likely that that
directory hierarchy has been NFS mounted read-only.
> > The fourth line ("replace") means that files normally installed in /usr/man
> > should be installed in /usr/share/man/ instead.
> >
> > The fifth line ("backup") means that files normally installed in /usr/share
> > should be installed in /usr/local/share/ instead, but to make sure that
> > those files already exist under /usr/share (this may be a network mounted
> > drive managed by another computer).
>
> shouldn't `backup' have { check, verify } refinements as well? If
> not, there's no safeguard against getting differing copies of the
> files installed.
We chose not to verify the contents of the file, but rather just its
existance. There may be a flag the user can set that will force a
comparison of the data instead of just existance.
> I haven't been following diety's evolution, so please pardon my
> ignorance.
>
> I infer from this that the package installation scenario would
> be for a manual package install to be run on each individual
> machine. The file server(s) would be updated first, then the
> workstations. On the workstations, it'd probably be common to
> see { delete, check, verify } in the local Policies file.
>
> However, some of the other threads on debian sysadmin topics
> leave me with the impression that the thinking is to do
> all package admin on a central machine (a file server,
> proobably), and to selectively propagate some portion of
> what's been installed (or updated, or removed) there out
> to other machines.
Both thoughts are correct. Admin can be done (eventually) from a central
machine. However, the actuall install will be run remotely and will use
the policies file on the destination machine.
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
the difference between theory and practice is less in theory than in practice
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: