On 2023/07/24 01:19, Pavel Korovin wrote: > > As I see it, @ask-update is mostly needed where you need to take steps > > _before_ the new version is installed (say, for postgresql if you're in > > a situation where you can't use pg_upgrade, e.g. using an extension, > > you need to run the old version in order to dump the db), Whereas if > > it's steps to be taken after updating, it doesn't really matter if > > people update first, they can still follow them. > > I'm OK with your approach, the only thing which makes me feel bad is > the situation when the user runs 'pkg_add -u' and then finds that gitea > fails to start and something has to be done now to fix it.
pkg_add -u will display MESSAGE if it changed since the previous version so the user can easily find information about how to fix it. (The downside is that it's displayed for new installs with "pkg_add gitea" too). Another way is simply to list changes needed in faq/current.html (which is usually copied over to the upgrade notes for the next OpenBSD release). But on an interactive update, this is easier to miss than MESSAGE. This situation (upstream requiring config changes) is not uncommon - unless things are likely to be a real mess we don't normally use @ask-update for them. The problem with @ask-update is that non-interactive updates just skip updating the relevant package; but sometimes after an OS update the old package is non-functional too. There are some exceptions in-tree: freeradius 2->3 and dovecot 1->2, where they have multiple configuration files which don't work well with the @sample mechanism and they had big changes that really needed attention, at least a backup, before the update. But it seems this is not really a problem with the changes needed for gitea?
