On Tue, Sep 17, 2019 at 01:15:06PM +0200, Paul de Weerd wrote:
> 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.
We actually know what file belongs to which set.
see /usr/lib/locate/src.db
