[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: