Re: Bug#688772: gnome Depends network-manager-gnome
On Wed, Dec 19, 2012 at 09:27:25PM +0100, Tollef Fog Heen wrote:
> ]] Colin Watson
>
> [...]
>
> > 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.
>
> While I think this position is reasonable, how should this be
> communicated to the administrator? Having to check postinst scripts for
> all packages that might interfere with network connectivity isn't really
> reasonable.
Well, let me make it clear that I think taking down network interfaces
during upgrades is very likely to be a bug. I just think that whether
it's RC should be a case-by-case decision depending on the scope of the
resulting problems.
If administrators are having to do extensive research to figure out
whether a remote upgrade is safe because packages are liable to tear
down the network underneath them, then, well, that's a good illustration
of why this whole issue is of concern in the first place, as Steve
articulated in
http://lists.debian.org/debian-ctte/2012/12/msg00009.html. I think a
system requirement should be that in general they do not have to do this
kind of extensive research.
The reason I'm equivocating here is that (a) I do not think that this
requirement is unique to NetworkManager, but (b) I'm aware that this is
a contentious thread and I don't want to suddenly find that I've made an
over-general statement which results in somebody upgrading lots of
essentially theoretical bugs to RC severity. People have come up with
enough strange types of network connectivity that I'm quite sure there
are grey areas here, and I'm not going to say categorically that any
interruption to any network interface of any kind at all during upgrade
is an RC bug, nor do I think it would be wise for the TC to say that.
At the same time, packages that are responsible for management of
network interfaces often find themselves in a specialised situation
relative to upgrades and accordingly deserve special consideration.
They are not generally Essential as such and generally shouldn't be, but
some of the same reasoning and constraints may need to apply to them.
After all, one of the reasons why we require that Essential packages
(or, in some cases, the essential facilities they provide) work
continuously even during upgrades is because some of them form
infrastructure for the upgrade itself.
> (I think 3G network interfaces will be more common than you believe, in
> particular for embedded setups. I've personally reconfigured multiple
> thousand power meters over 3G links, and if that particular upgrade had
> gone awry, the company I did the work for would have incurred a cost in
> the millions of NOK, since they'd have to send people to each location
> to reinitialise the meters. This is a bit of an extreme example and not
> particularly common, but the impact can be very large.)
Fair enough; it was just an example (and probably not a very good one)
rather than anything intended to be normative. This would be a decent
case-by-case argument for increasing the severity of such a hypothetical
bug. And this is just my point: we should be considering the real-world
situations involved rather than making a blanket statement that
something interrupted a network interface so it must be RC.
--
Colin Watson [cjwatson@debian.org]
Reply to: