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?), ...
