Re: How to warn user about breaking change in location of runtime file?
Hi,
Leonid Borisenko wrote:
> I want to move socket location from '/run/uwsgi/<confname>/socket' to
> '/run/uwsgi/app/<confname>/socket'. If user relied on socket location,
> then upgrade of uwsgi package will require manual editing of frontend
> server configuration. Until editing (and reloading of upstream server),
> behavior of the whole server stack will be broken.
[...]
> I've asked about it in debian-mentors [1]. In short: I've asked for
> advice in choosing between: 1) mentioning of change in NEWS.Debian, 2)
> providing debconf note, 3) both 1. and 2., 4) something else. I've
> recieved no answers though.
uwsgi was never in a stable release and users have only had a few
weeks to get used to the current behavior, so I'd suggest mentioning
the change and what configuration change might be needed in
NEWS.Debian and leaving it at that.
Still, I like this question so much that I think it deserves a more
thorough answer. So imagine that the old socket location had been
used for a longer period; what could you do? Just mentioning the
change in NEWS is not so pleasant, since it requires action on the
part of the sysadmin. In that case, I believe your best option would
be to provide a symlink in /run/uwsgi/<confname>/socket to the new
location and file a bug against the release-notes package to document
that this symlink would disappear in (next Debian release)+1.
In some configurations, a debconf note blocks the installation until a
human has acknowledged it, which might seem like an appealing feature.
NEWS.Debian.gz entries work even better (if apt-listchanges is
installed), since they are shown before the preconfiguration stage of
an upgrade begins, allowing the administrator to back out if it is not
a good time. Once an upgrade begins, they do not interfere, and after
the upgrade, they are easy to inspect automatically or by hand. The
reasons described at [*] also apply, of course.
Thanks for your work, and hope that helps.
Jonathan
[*] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#s6.5.1
Reply to: