On Fri, Dec 14, 2012 at 10:00:33AM -0800, Russ Allbery wrote: > Tollef Fog Heen <tfh...@err.no> writes: > > Is this a requirement for other network-providing packages as well? If > > so, openvpn for instance is RC-buggy because upgrading it will restart > > any configured VPNs. We don't require other packages to continue to > > work uninterrupted during upgrades, > > I think we actually do require that in some cases. OpenSSH, the X server, > and GDM come immediately to mind.
While nobody's ever told me that this is a requirement as such, I consider it one on my own account as OpenSSH maintainer. It's just so common to perform upgrades over SSH that I'd consider it irresponsible to break that. (And fortunately the design of the OpenSSH server is such that it tends to just work.) For network-providing packages in general, I'd want to think about it case by case, and I think it would depend on how common it is to perform upgrades over the network interfaces they implement or support. openvpn is commonly used, for instance, by people working at home to access their employer's network, and in that case an interruption during upgrade is not so important. If it's common to operate in reverse and upgrade a system at the "client" end of an openvpn link, then that would be a good argument for upgrading the severity of such a bug. Some types of networking are just so rarely used as anything other than a means of getting connectivity in network-poor locations that I would have a very hard time arguing that their interruption during upgrades could be release-critical. For instance, if a 3G network interface went down during upgrade, or the client end of an IP-over-DNS link, then that's ungraceful and could be handled more smoothly, but I don't think it's RC. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121219114445.ga12...@riva.dynamic.greenend.org.uk