Re: How to warn user about breaking change in location of runtime file?
Hi Jonathan,
Thanks for comprehensive and very helpful answer!
[top-posted because it was difficult to find something valueless to
skip for getting rid of reply scrolling]
On 06.07.2011 10:22, Jonathan Nieder wrote:
> 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: