On Tue, Sep 17, 2019 at 09:39:00AM +0100, cho...@jtan.com wrote:
| Marc Espie writes:
| > On Tue, Sep 17, 2019 at 09:01:47AM +0100, cho...@jtan.com wrote:
| > > Marc Espie writes:
| > > > I'm a bit surprised nobody looked at instrumenting what sets are
actually
| > > > installed on a machine during install/manual upgrade and cloning that
| > > > into sysupgrade to avoid this kind of surprise...
| > >
| > > I mentioned the possibility wrt. syspatch but it was rejected in favour
| > > of expecting users to run a default system or, in effect, become
| > > developers. Not a stance I entirely agree with but which nevertheless
| > > has its merits.
| >
| > But sysupgrade is a much "simpler" mechanism than syspatch.
| >
| > More importantly,
| > - sysupgrade is definitely about the sets
| > - if you have a non default installation, syspatch happens *at user level*
| > so you have every opportunity to figure out what's going on.
| > Where sysupgrade ? reboot the machine, see your disks overflow. Boom machine
| > kaput.
|
| The problem boils down to: how does sysupgrade, or any other tool, know
| which sets have been installed?
By having each set install a specific file in a well-known location.
Before sysupgrade I wrote my own script to upgrade machines, this uses
/var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
determine what has been installed and upgrade only those sets.
However, the argument that not installing all sets gives you a 'non
standard' system suggests that this approach isn't viable.
Cheers,
Paul 'WEiRD' de Weerd
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
