Marc Espie writes: > On Tue, Sep 17, 2019 at 09:01:47AM +0100, [email protected] 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? That information is not tracked anywhere to the best of my knowledge. sysupgrade would have to determine which sets are installed either by heuristics, making its code much more complicated, or by being informed by the user, recursing back to the initial problem - perform maintainence who's actions differ depending on which sets are installed without the user being required to keep track of that set of sets. Or by abandoning an installation process as simple as 2½ steps. Don't get me wrong, I'd love it if those tools tracked sets such that they could be treated a little more like The Other Side handles the entire operating system as a set of packages, but it's not as simple a problem to solve as it initially appears, as if it ever is, which is why I didn't push the issue. Just see the plethora of package managers that exist. Matthew
