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

Bug#688772: gnome Depends network-manager-gnome



On Fri, Dec 14, 2012 at 10:00:33AM -0800, Russ Allbery wrote:
> Tollef Fog Heen <tfheen@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                                       [cjwatson@debian.org]


Reply to: