On 2023/07/23 16:05, Pavel Korovin wrote:
> I think adding @ask-update makes sense only if there's an UPGRADE section in
> README describing what setting is deprecated in which version, otherwise
> I'll end up with multiple @ask-update for each version, or with @ask-update
> for all versions with something misleading like: "check your config for
> deprecated settings", but how people will know what's deprecated?
Users can't see a new pkg-readme on the running system until they've
already agreed to accept the update.
> From the recent security/gnupg update which broke yubikey setups,
> there's no @ask-update but there's an additional note in README.
I've veen pondering that one. Unless there's some indication that the
internal ccid driver does actually work in some cases on OpenBSD, I
think it maybe worth patching to disable it.
> So I see 3 options:
> 1) Add UPGRADE section in README with the list of deprecated config
> options
> 2) 1) + @ask-update
> 3) 1) + @ask-update for each specific version (not sure if it even
> works)
IMHO I would go with 4) - 1) and a short pkg/MESSAGE "if updating from
before X.Y, see the pkg-readme for config options which are no longer
supported". ("deprecated" is "still work but you should stop using them"
rather than "no longer works and things break unless you remove them").
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.
