On 07/24, Stuart Henderson wrote: > 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?
Gitea is a go binary, so in most cases the old package won't become non-functional very soon. I'd leave @ask-update with a message like: "gitea-v1.20.0 fails to start if configuration contains deprecated options, make sure your configuration is up-to-date" And leave it for a user to decide about his config. Because: 1) There's a list of deprecated options, and gitea blames those in logs, but still works 2) There are some deprecated options like those in [mailer] section which make gitea silently fail 3) People can use different options in their configs. I cannot test which one will break Gitea this or next time I think it's the app problem, and Gitea devs still din't decide how to fix it, e.g.: https://github.com/go-gitea/gitea/pull/25206#issuecomment-1621292395 I'd better not keep trying to fix in the port the problems which should be fixed in the app itself. -- With best regards, Pavel Korovin
