On Tue, Nov 19, 2019 at 09:00:33AM +0000, Stuart Henderson wrote: > On 2019/11/18 14:45, Raimo Niskanen wrote: > > On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote: > > > > > > > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote: > > > > > > > A configuration parameter could be accomplished through an optional > > > > symlink > > > > /etc/_sysupgrade that the sysadmin can create to point at the > > > > installation's > > > > sysupgrade directory. The sysupgrade script would test -s > > > > /etc/_sysupgrade > > > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR. > > > > > > > > > > As it was said earlier, this doesn't solve the removal issue. With your > > > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade". > > > > > > > This is actually not yet in my patch. I just want to, as a first step > > towards either of our solutions, patch to have the /home/_sysupgrade literal > > in only one place in the sysupgrade script, which would facilitate patching > > the sysupgrade script before calling it, as a poor man's solution. > > Plus, the script gets cleaner. > > > > The symlink suggestion is a future patch. > > > > But I think your suggestion to instead specify the parent directory of the > > _syspatch directory should be sufficient to remedy the removal issue both > > for your command line suggestion, as for this future patch symlink > > suggestion. > > > > It is a pity nobody else has responded to that prefix suggestion of yours! > > It does avoid the removal issue but it seems an awkward user interface to > pass the parent directory. Perhaps better to enforce that the path matches > */_sysupgrade, though this also doesn't feel quite right. Perhaps add > /_sysupgrade if it wasn't already present... > > > I think the feature itself is more important than if it is implemented > > with a command line argument or a symlink. > > > > Other than that. What do you or anyone else think about my argument that > > the location of the system upgrade download directory is an installation > > configuration that will not change between upgrades and hence it would be > > nice to not have to remember the command line argument for every future > > sysupgrade. > > Generally agree, but I'm not keen on a proliferation of tiny pseudo-config > files, and this feels maybe part of something bigger. A similar argument > could be made for the choice of release/stable vs snaps (-s / -r here, > -Dsnap in pkg_add) which could be in some kind of "system config" alongside > source URLs (base, packages, firmware), a list of sets, maybe some pkg_add > related things (whether to install debug packages?), ...
In that case, in the current state of the matter, since there is no such common config file yet, and all other tols use command line arguments for similar features, we should use a command line argument here too, like Renaud Allard proposes. Until there is a suitable config file. Since the prefix solution is regarded as awkward, and we want go guard against clumsy admins using / as sysupgrade directory which would remove kernels from the updated installation, why not normalize the -d argument with readlink -f and simply check that it is not / . There are of course othere directories that are inappropriate to use, but the person doing the upgrade has to be trusted to some degree... And I see no reason to not at least apply my minimalistic patch suggestion that simply defines the upgrade directory in only one place in sysupgrade. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
