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 > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1589df.5000...@gmail.com
