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
Yes. > */_sysupgrade, though this also doesn't feel quite right. Perhaps add > /_sysupgrade if it wasn't already present... Or, since readlink -f normalizes the path one could simply check that the result is not / which should fix the important case. > > > 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?), ... Agreed. /etc/installurl is now a tiny one item config file but was once a different file containing more items. Perhaps something to go back to? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
