subject:"Bug#688772\: gnome Depends network\-manager\-gnome"

On Fri, Dec 14, 2012 at 01:35:49PM +0100, Philipp Kern wrote:
> On Fri, Dec 14, 2012 at 12:18:31AM -0800, Steve Langasek wrote:
> > (Furthermore, I think the whole idea of needing custom desktop
> > infrastructure to tell apps whether they're online or not is silly;
> > you're online if you have a default route. [...]

> I know that you put it in braces because it's not your main point. Still
> I don't think this is true. Other proprietary (and some open) OSes now
> have elaborate measurement facilities to check if they're online. They
> detect captive portals and tell you to login, they detect if just IPv6
> is broken, but IPv4 works, the other way around, they might even detect
> if DNS64 and NAT64 are in use. (Coming from an IPv6 background.)

> I don't want applications to be stuck connecting to stuff if they're not
> really online. Obviously TCP will retry the handshake for some time
> but it will still require manual action of reconnecting pidgin if
> the network access is finally granted. On the other hand one could
> argue that the network resources pidgin would need could already be
> available when there's no default route.

> So centralizing the knowledge what it takes for a network connection to
> be considered up (for which n-m gives you basic means like requiring
> IPv4 and/oror requiring IPv6 to be up on a given interface) makes a lot
> of sense. And it could still be improved.

Fair point.  The main idea I was trying to express wasn't that having such a
higher-level network connectivity service was somehow redundant or useless,
but the importance of failing *open* when the service is absent or operating
with incomplete information.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#688772: gnome Depends network-manager-gnome

On Fri, Dec 14, 2012 at 10:23:58PM +0100, Tollef Fog Heen wrote:

> > I think it's important that an upgrade of the NM package *also* not cause
> > the network to drop, but that's a slightly different point than the one I
> > was meaning to make.

> My question then still stands: Do you consider NM in any way special
> here or does the same requirement apply to other network-providing apps?

I think NM is quantitatively different from other network-providing
packages, but not qualitatively so, because NM purports to manage the
primary network connection.  If you're remotely connected to a machine over
openvpn, and you upgrade the openvpn package, and you are then surprised
that the connection drops in the middle while the openvpn server restarts,
well...  that's a bug, but I'm not sure why you as the admin weren't
prepared to deal with that.  OTOH, if you upgrade the quagga package and it
flushes your entire network's BGP table (to take a historical example),
that's a serious issue.

So NM is special in that it's important.  Other packages that provide
similar management of the primary network connection are similarly
important.

> > The policy requirement isn't that *filesystem* changes be preserved, it's
> > that *configuration* changes be preserved.  In what way does deleting
> > /etc/network/interfaces constitute a valid configuration that must be
> > preserved?

> The policy requirement is not that the configuration changes are
> valid.

The policy requirement specifically says that:

 Configuration file handling must conform to the following behavior:
* local changes must be preserved during a package upgrade

You're right that validity is not mentioned.  But I consider this a very
broad gray area open to interpretation, and I think all of the following are
legitimate, non-buggy (and especially not RC-buggy) actions for a package to
take:

  - update a configuration file on upgrade to drop deprecated,
user-specified configuration options that are no longer supported (and
which may cause the package to stop working)
  - convert the configuration file on upgrade from one format to another,
preserving any user changes to the configuration settings but not the
text of the config file
  - modify a config file to recover from known software-induced damage, even
though it is impossible to determine with certainty that a particular
file was damaged by software vs. by explicit admin action
  - recreate a template config file on upgrade if missing, where the
contents of that config file correspond to the default behavior of the
software when not configured at all
  - fail to complete package configuration while the config file is invalid,
requiring the admin to fix it manually.

I think recreating a stock non-conffile config file when it's been removed
is just one more point along this continuum.  You might consider it a bug to
recreate the file, but I see no basis for considering it a policy violation.

And by the way, if you're going to treat it as a serious bug, you'd better
get filing other bugs for consistency.  Just off the top of my head,
base-passwd has had the same handling of /etc/passwd for *years* without
anyone objecting.  To me, this is very clearly a matter of moving the goal
posts.

> It's not ok to replace a config file just because it has a syntax error in
> it, is it?  Also, see below.

Replace, no.  Repair, maybe.

> > When ifupdown recreates the file, it populates it only with a
> > config for lo.  I don't think it's reasonable to claim that it's valid and
> > intentional to configure a system in such a way that it will fail to bring
> > up the loopback interface on boot.  In fact, booting the system without lo
> > breaks so many assumptions that Ubuntu, for example, *unconditionally*
> > brings up lo on boot, whether or not it's configured in
> > /etc/network/interfaces.  I consider restoring a stock /e/n/i on package
> > upgrade to be in the same category.

> Putting «iface lo» into /etc/network/interfaces is not only a way to
> ensure there is a loopback interface on boot. It's also a way for
> ifupdown to claim to handle that interface (this is a natural
> consequence of the CTTE ruling; that ifupdown is special and has
> precedence and other tools should stay away from interfaces where there
> is a ifupdown configuration for the interface), so if ifupdown does add
> that configuration, there is no way for me to have ifupdown installed so
> I can read the man page at the same time as letting other tools manage
> lo.

I don't see where the previous TC ruling says that ifupdown is special. 
Rather, it says that upgrading gnome-core shouldn't cause network-manager to
clobber the user's network preferences on upgrade, /whichever/ tool they
were using to manage those.

That should be trivially easy in the case of lo.  If the /e/n/i entry for lo
is missing, or matches this:

  iface lo inet loopback

... it's fair game.  If it's something else,

Bug#688772: gnome Depends network-manager-gnome

2012-12-14 Thread Tollef Fog Heen

]] Steve Langasek 

> On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote:
> > ]] Steve Langasek 
> 
> > >  - Installing the gnome or the NM package must not cause the network to
> > >break on upgrade, even temporarily, under any circumstances.
> 
> > 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, and while I can agree NM is in a bit
> > of special situation by virtue of controlling the network, I am not sure
> > being as strict as you are here is reasonable.
> 
> Sorry, my wording was a bit sloppy there.  What I meant to say was, "an
> upgrade that pulls in either gnome or network-manager as a new package must
> not cause the network to break, even temporarily".  So on new installation
> of the NM package, my expectation is that it will not tamper with the
> current network state, because doing so may break the admin's remote
> connection to the machine.

Ok, fair enough.

> I think it's important that an upgrade of the NM package *also* not cause
> the network to drop, but that's a slightly different point than the one I
> was meaning to make.

My question then still stands: Do you consider NM in any way special
here or does the same requirement apply to other network-providing apps?

> > >  - Installing the gnome or the NM package must not cause any network
> > >configuration the user has specified to be lost.
> 
> > This is reasonable, and makes ifupdown RC-buggy, since rm-ing
> > /etc/network/interfaces and reinstalling the package will change the
> > network configuration (the file is recreated).  I've just filed a bug
> > about this.
> 
> I think you're missing several steps in your proof that this is RC buggy. ;)

I had enough steps in there that one of the release managers agreed with
me.

> The policy requirement isn't that *filesystem* changes be preserved, it's
> that *configuration* changes be preserved.  In what way does deleting
> /etc/network/interfaces constitute a valid configuration that must be
> preserved?

The policy requirement is not that the configuration changes are
valid. It's not ok to replace a config file just because it has a syntax
error in it, is it?  Also, see below.

> When ifupdown recreates the file, it populates it only with a
> config for lo.  I don't think it's reasonable to claim that it's valid and
> intentional to configure a system in such a way that it will fail to bring
> up the loopback interface on boot.  In fact, booting the system without lo
> breaks so many assumptions that Ubuntu, for example, *unconditionally*
> brings up lo on boot, whether or not it's configured in
> /etc/network/interfaces.  I consider restoring a stock /e/n/i on package
> upgrade to be in the same category.

Putting «iface lo» into /etc/network/interfaces is not only a way to
ensure there is a loopback interface on boot. It's also a way for
ifupdown to claim to handle that interface (this is a natural
consequence of the CTTE ruling; that ifupdown is special and has
precedence and other tools should stay away from interfaces where there
is a ifupdown configuration for the interface), so if ifupdown does add
that configuration, there is no way for me to have ifupdown installed so
I can read the man page at the same time as letting other tools manage
lo.

I might also dislike the name «lo» for loopback and rename the lo
interface to something else, and let «lo» be the name of yet another
interface. It's a bit crazy, but not much cares about network interface
names apart from the network configuration tools, so this would actually
break a most unusual, but otherwise valid configuration of the network
stack.  ifupdown would break that configuration.

> If the reason you raise this concern is because of my comment that NM should
> always report the system "online" unless it controls all the network
> interfaces, I was implicitly excluding lo from the reckoning.  First,
> it's not relevant to whether the machine is online, and second, there's only
> one valid state for this interface ("up") so there's no configuration to
> fight over the management of.

Your mail triggered me to go look, but it wasn't otherwise directly
related, no.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

--
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/87vcc4ba4x@xoog.err.no

Bug#688772: gnome Depends network-manager-gnome

On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote:
> ]] Steve Langasek 

> >  - Installing the gnome or the NM package must not cause the network to
> >break on upgrade, even temporarily, under any circumstances.

> 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, and while I can agree NM is in a bit
> of special situation by virtue of controlling the network, I am not sure
> being as strict as you are here is reasonable.

Sorry, my wording was a bit sloppy there.  What I meant to say was, "an
upgrade that pulls in either gnome or network-manager as a new package must
not cause the network to break, even temporarily".  So on new installation
of the NM package, my expectation is that it will not tamper with the
current network state, because doing so may break the admin's remote
connection to the machine.

I think it's important that an upgrade of the NM package *also* not cause
the network to drop, but that's a slightly different point than the one I
was meaning to make.

> >  - Installing the gnome or the NM package must not cause any network
> >configuration the user has specified to be lost.

> This is reasonable, and makes ifupdown RC-buggy, since rm-ing
> /etc/network/interfaces and reinstalling the package will change the
> network configuration (the file is recreated).  I've just filed a bug
> about this.

I think you're missing several steps in your proof that this is RC buggy. ;)
The policy requirement isn't that *filesystem* changes be preserved, it's
that *configuration* changes be preserved.  In what way does deleting
/etc/network/interfaces constitute a valid configuration that must be
preserved?  When ifupdown recreates the file, it populates it only with a
config for lo.  I don't think it's reasonable to claim that it's valid and
intentional to configure a system in such a way that it will fail to bring
up the loopback interface on boot.  In fact, booting the system without lo
breaks so many assumptions that Ubuntu, for example, *unconditionally*
brings up lo on boot, whether or not it's configured in
/etc/network/interfaces.  I consider restoring a stock /e/n/i on package
upgrade to be in the same category.

If the reason you raise this concern is because of my comment that NM should
always report the system "online" unless it controls all the network
interfaces, I was implicitly excluding lo from the reckoning.  First,
it's not relevant to whether the machine is online, and second, there's only
one valid state for this interface ("up") so there's no configuration to
fight over the management of.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

signature.asc
Description: Digital signature

Bug#688772: gnome Depends network-manager-gnome

2012-12-14 Thread Russ Allbery

Tollef Fog Heen  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.

-- 
Russ Allbery (r...@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/87pq2cy0n2@windlord.stanford.edu

Re: Bug#688772: gnome Depends network-manager-gnome

2012-12-14 Thread Philipp Kern

On Fri, Dec 14, 2012 at 12:18:31AM -0800, Steve Langasek wrote:
> (Furthermore, I think the whole idea of needing custom desktop
> infrastructure to tell apps whether they're online or not is silly;
> you're online if you have a default route. [...]

I know that you put it in braces because it's not your main point. Still
I don't think this is true. Other proprietary (and some open) OSes now
have elaborate measurement facilities to check if they're online. They
detect captive portals and tell you to login, they detect if just IPv6
is broken, but IPv4 works, the other way around, they might even detect
if DNS64 and NAT64 are in use. (Coming from an IPv6 background.)

I don't want applications to be stuck connecting to stuff if they're not
really online. Obviously TCP will retry the handshake for some time
but it will still require manual action of reconnecting pidgin if
the network access is finally granted. On the other hand one could
argue that the network resources pidgin would need could already be
available when there's no default route.

So centralizing the knowledge what it takes for a network connection to
be considered up (for which n-m gives you basic means like requiring
IPv4 and/oror requiring IPv6 to be up on a given interface) makes a lot
of sense. And it could still be improved.

Kind regards
Philipp Kern

signature.asc
Description: Digital signature

Re: Bug#688772: gnome Depends network-manager-gnome

2012-12-14 Thread Tollef Fog Heen

]] Steve Langasek 

>  - Installing the gnome or the NM package must not cause the network to
>break on upgrade, even temporarily, under any circumstances.

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, and while I can agree NM is in a bit
of special situation by virtue of controlling the network, I am not sure
being as strict as you are here is reasonable.

>  - Installing the gnome or the NM package must not cause any network
>configuration the user has specified to be lost.

This is reasonable, and makes ifupdown RC-buggy, since rm-ing
/etc/network/interfaces and reinstalling the package will change the
network configuration (the file is recreated).  I've just filed a bug
about this.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/877gol9fvm@qurzaw.varnish-software.com

Bug#688772: gnome Depends network-manager-gnome

Hi Noel,

On Tue, Nov 13, 2012 at 07:23:51PM +, Noel David Torres Taño wrote:

> My main concern when raising #681834 is that NM breaks my desktop system,
> not by breaking its network, but but rendering some of its applications
> unusable.  This seems not to have been addressed yet.

> The example I put once and again is that when I use pidgin, if NM is
> installed (and since my network is configured statically in /e/n/i) pidgin
> thinks I have no working network connection (which I have) and refuses to
> connect, while with NM not installed pidgin works properly.

I believe this is out of scope of the current question; but for the record,
I would consider that an obvious and release-critical bug in NM if having NM
installed but disabled in favor of static /etc/network/interfaces causes
applications to consider themselves "offline".  The correct default behavior
when NM is not in control of the network is to assume that the system is
*on*line.  (Furthermore, I think the whole idea of needing custom desktop
infrastructure to tell apps whether they're online or not is silly; you're
online if you have a default route.  Everything else - like deciding you
don't want to use your expensive 3G connection for certain kinds of data use
- is valuable, but it's icing; and it should never cause an app to fail to
use the perfectly good network just because this additional desktop service
is unavailable.)

I'm pretty sure even without talking to him that the NM maintainer would
agree with me that the following are requirements for NM's "are we online?"
API:

 - If NM is not installed, the app must assume you're online.
 - If NM is installed but disabled (not running), the app must assume you're
   online.
 - If NM is installed and running but knows that it's not managing one or
   more network connections (because these are configured in, e.g.,
   /etc/network/interfaces instead), NM must tell apps that they are online.
 - If NM is configured to control all interfaces it knows about on the
   system, only then is it allowed to tell apps if they are on or off line.

If any of this is controversial, I'm happy to discuss it further - but I
think this would be best done via a bug report against network-manager, not
via the technical committee.  Regardless, as failure to comply with any of
the above would be a plain - and plainly fixable - bug in NM and associated
libraries, I don't think that such a bug is a reason for me to vote against
a gnome dependency on NM.  Like many of the bugs that have been described in
this thread, any of the above are things that should be fixed for the good
of our users *regardless* of whether gnome depends on NM.

> This is the reason for which I consciously decided to deinstall NM knowing
> that it breaks a Recommends.  It was an explicit decision by me (the
> user), and having it overruled by the Debian Gnome team caused me some
> problems (yes, I do not track stable but unstable).

> I'm happy with NM being installed by default (I want it on my next laptop, 
> which will use Debian Gnome), but I also want my decision to deinstall it 
> being respected.

From my perspective, this is overspecifying the solution.  Being able to
arbitrarily uninstall a dependency of a package, regardless of which package
or why it's there, is not a requirement of Debian.  And indeed, if you
really want to countermand the maintainer regarding a package dependency,
there's always the 'equivs' tool for that.  The requirements that we
*should* have for the system, and that I think everyone can agree on, are:

 - Installing the gnome or the NM package must not cause the network to
   break on upgrade, even temporarily, under any circumstances.
 - Installing the gnome or the NM package must not cause any network
   configuration the user has specified to be lost.
 - Whenever it is possible to determine the user's preference, installing
   the gnome or the NM package must not cause settings in another
   configuration location (either /e/n/i or elsewhere) to be superseded by
   configuration in NM's own internal database, even if the configuration is
   functionally equivalent.
 - Installing the gnome or the NM package must not interfere with the
   functionality of other network configuration GUI tools in other desktop
   environments, because having gnome (or network-manager) installed is not
   an indication that the admin wants to *use* it.

The key point here is that all the things that are problematic about
network-manager taking over the network configuration when pulled in as a
dependency on gnome are *also problematic if they happen when installing
network-manager directly*.  The only difference is the number of users
affected in each case.

If the GNOME Team and NM maintainer can assure us that all of the above
requirements are met, and that any currently-undiscovered bugs with respect
to these requirements could be fixed in a reasonable time frame for the
wheezy release, then I have no reason at all to

Bug#688772: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]

2012-12-02 Thread Russ Allbery

Don Armstrong  writes:

> Ok, so this option C would involve not overriding the maintainer,
> coupled with requesting documentation in the release notes, and would
> also supplant 5 and 6 in the A and B versions.

Ah, yes, indeed, it would.

> I've gone ahead and updated the current don_draft.txt with this text
> as written with the other options.

Thanks!

> I believe that the fixes outlined in option B are going to get
> implemented regardless of how the CTTE rules; the primary goal of B is
> to make the gnome dependency on NM conditional on those fixes being
> implemented. [And if that's not clear from the text of B, that's
> something that I would like to resolve.]

If that does happen, of course, I'm happy to support B.  I don't know how
much progress has already been made on that.

-- 
Russ Allbery (r...@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/87d2ysqfwf@windlord.stanford.edu

Bug#688772: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]

2012-12-02 Thread Don Armstrong

On Sun, 02 Dec 2012, Russ Allbery wrote:
> Don Armstrong  writes:
> > This is the current text of the options for #688772. I'd like to vote on
> > this before the 9th if at all possible. If anyone has any comments,
> > changes, or would like to propose different options, please do so now.
> 
> After considering this and following the discussion, I'm not willing
> to vote for either A or B, and would end up voting further
> discussion. I'd like to add an option C, along the lines of:

[...]

Ok, so this option C would involve not overriding the maintainer,
coupled with requesting documentation in the release notes, and would
also supplant 5 and 6 in the A and B versions.

I've gone ahead and updated the current don_draft.txt with this text
as written with the other options.

> In other words, my *preferred* option is B with the fix to the
> network-manager package, but B as phrased has consequences for not
> getting that fix done in time that I'm not comfortable with.

I believe that the fixes outlined in option B are going to get
implemented regardless of how the CTTE rules; the primary goal of B is
to make the gnome dependency on NM conditional on those fixes being
implemented. [And if that's not clear from the text of B, that's
something that I would like to resolve.]

Don Armstrong

-- 
He was wrong. Nature abhors dimensional abnormalities, and seals them
neatly away so that they don't upset people. Nature, in fact, abhors a
lot of things, including vacuums, ships called the Marie Celeste, and
the chuck keys for electric drills.
 -- Terry Pratchet _Pyramids_ p166

http://www.donarmstrong.com  http://rzlab.ucr.edu

-- 
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/20121202214247.gf5...@teltox.donarmstrong.com

Bug#688772: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]

2012-12-02 Thread Russ Allbery

Don Armstrong  writes:

> This is the current text of the options for #688772. I'd like to vote on
> this before the 9th if at all possible. If anyone has any comments,
> changes, or would like to propose different options, please do so now.

After considering this and following the discussion, I'm not willing to
vote for either A or B, and would end up voting further discussion.  I'd
like to add an option C, along the lines of:

4. After further discussion, we understand that reintroducing
   network-manager on upgrade was part of the intent, due to both
   substantial improvements in network-manager and tighter integration of
   network-manager with the GNOME desktop in wheezy.  Since the gnome
   metapackage has historically been more aggressive at pulling in
   additional packages, we believe the move of the dependency from
   gnome-core to gnome is an acceptable compromise that was not raised
   during the previous discussion.  Users who want to remove
   network-manager can still use the gnome-core metapackage to get the
   basic GNOME desktop functionality.

   We recommend that this upgrade behavior for users of the gnome
   metapackage be documented in the release notes.

This is not to say that I'm opposed to fixing network-manager to deal with
some of the other upgrade problems.  I'm all in favor!  But I'm not
comfortable with making inclusion of the dependency conditional on solving
the broader problem in the way described there.  If it happens in time for
the release, I'm all in favor, and it makes it an even better compromise,
but I think it would be acceptable to release without that fix and
document the issue in the release notes.

In other words, my *preferred* option is B with the fix to the
network-manager package, but B as phrased has consequences for not getting
that fix done in time that I'm not comfortable with.

-- 
Russ Allbery (r...@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/871uf8ryzy@windlord.stanford.edu

Bug#688772: Current options for resolving 688772 [Re: Bug#688772: gnome Depends network-manager-gnome]

2012-12-02 Thread Don Armstrong

This is the current text of the options for #688772. I'd like to vote
on this before the 9th if at all possible. If anyone has any comments,
changes, or would like to propose different options, please do so now.

=== START ===

1. The TC notes the decision of the meta-gnome maintainers to
   implement the TC decision in #681834 by:
(a) softening the dependency in the gnome-core metapackage
from Depends to Recommends, as required
(b) adding a new dependency in the gnome metapackage,
as a Depends.  (In squeeze, this is where the dependency
was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheezy.

3. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

A 4. We overrule the decision of the meta-gnome maintainers to add a
Adependency from gnome to network-manager-gnome; this dependency
Ashould be removed for the release of wheezy.

B 4. We overrule the decision of the meta-gnome maintainers to add a
Bdependency from gnome to network-manager-gnome; this dependency
Bshould be removed. If in the opinion of the NM maintainer (and
Bbefore the release of wheezy the Release Managers) the concerns
Braised in §4 of the CTTE decision #681834 have been addressed
Bthrough technical means (e.g. by preventing the starting of NM as
Bdiscussed in #688772), the meta-gnome maintainers may freely
Badjust the dependencies as usual.
B
BSpecifically, valid bugs where existing valid network
Bconfigurations are broken by the automatic, required installation
Bon system upgrade of packages not previously installed which
Bperform network configuration on should have severity serious.

5. We request that the Release Team unblock update(s) to meta-gnome so
   that our decisions may be implemented in wheezy.

6. We request that a release note is created explaining that gnome
   users who do not currently have NM installed consider installing
   it.

=== END ===


Don Armstrong

-- 
Every gun that is made, every warship launched, every rocket fired
signifies [...] a theft from those who hunger and are not fed, those
who are cold and are not clothed. This world in arms is not spending
money alone. It is spending the sweat of its laborers, the genius of
its scientists, the hopes of its children. [...] This is not a way of
life at all in any true sense. Under the cloud of threatening war, it
is humanity hanging from a cross of iron. [...] [I]s there no other
way the world may live?
 -- President Dwight D. Eisenhower, April 16, 1953

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20121202194016.gc5...@teltox.donarmstrong.com

Bug#688772: gnome Depends network-manager-gnome

2012-11-26 Thread Don Armstrong


I've readjusted option B yet again, by adding an additional paragraph
which takes into account Ian's and Tollef's concerns. (git 6e42994)

B 4. We overrule the decision of the meta-gnome maintainers to add a
Bdependency from gnome to network-manager-gnome; this dependency
Bshould be removed. If in the opinion of the NM maintainer (and
Bbefore the release of wheezy the Release Managers) the concerns
Braised in §4 of the CTTE decision #681834 have been addressed
Bthrough technical means (e.g. by preventing the starting of NM as
Bdiscussed in #688772), the meta-gnome maintainers may freely
Badjust the dependencies as usual.
B
BSpecifically, valid bugs where existing valid network
Bconfigurations are broken by the automatic, required installation
Bon system upgrade of packages not previously installed which
Bperform network configuration on should have severity serious.


Don Armstrong

-- 
"Do you need [...] [t]ools? Stuff?"
"Our opponent is an alien starship packed with atomic bombs. [...] We
have a protractor."
 -- Neal Stephenson _Anathem_ p320

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20121127004245.go5...@rzlab.ucr.edu

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-13 Thread Noel David Torres Taño

Hi all

I do not know if you remember I am one of the interested parties on this, 
since I raised #681834.

I'm very happy of reading such a comprehensive and rational statament from the 
Gnome maintainers. I really appreciate it.

Please note that I am a (part time) Gnome user and want to continue being so.

My main concern when raising #681834 is that NM breaks my desktop system, not  
by breaking its network, but but rendering some of its applications unusable. 
This seems not to have been addressed yet.

The example I put once and again is that when I use pidgin, if NM is installed 
(and since my network is configured statically in /e/n/i) pidgin thinks I have 
no working network connection (which I have) and refuses to connect, while 
with NM not installed pidgin works properly.

This is the reason for which I consciously decided to deinstall NM knowing 
that it breaks a Recommends. It was an explicit decision by me (the user), and 
having it overruled by the Debian Gnome team caused me some problems (yes, I 
do not track stable but unstable).

I'm happy with NM being installed by default (I want it on my next laptop, 
which will use Debian Gnome), but I also want my decision to deinstall it 
being respected.

More to-the-point comments below.

On Martes, 13 de noviembre de 2012 09:19:18 Jordi Mallach wrote:
> Hi,
> 
> The Debian GNOME team is well aware of the discussion regarding #688772,
> which unfortunately went down an unconstructive path. As such we thought
> it best to step back for a little bit to try and formulate our position
> more clearly and see if we could find a constructive way to get out of
> this mess. Luckily the last few mails on the thread by Don Armstrong and
> Michael Biebl already showed there was some light at the end of the tunnel
> :)
> 
> First of all, we want to make clear that the position Joss has been
> defending on this exhausting thread is shared by most, if not all, of the
> Debian GNOME team members. In other words, we all consider NM an important
> and integral part of the desktop system we're delivering, and its absence
> does degrade its operation in such a way we find inacceptable.

I am a Gnome user, and I find Gnome without NM beyond acceptable: it is 
perfectly usable. I'm using it to write this.
> 
> It is worth to point out that GNOME 3 as we will get in wheezy is a big
> departure from the GNOME 2 as delivered in lenny. Among other things GNOME
> now strives for a tightly integrated desktop, with NM being a core part of
> this desktop. In the opinion of the GNOME team the intended GNOME
> experience can only be delivered when all these tightly integrated parts
> are used together.

It should be up to the user to decide up to which completion point he desires 
an experience.
> 
> Network manager is  not an arbitrary requirement, even if GNOME Shell can
> currently run without it. NetworkManager allows GNOME to:
> - access all present and commonly used networking technologies (VPN,
> Wireless, 3G) via an integrated, very prominent icon in the main desktop
> bar. - networking needs have changed over the past years and has become
> much more dynamic and diverse. Connecting to the internet via wireless, 3G
> or VPN should be painless and easy. It should work out of the box and
> require a minimum of fuss.
> - only NetworkManager currently offers this kind of features, ifupdown is
> too static/cumbersome to setup, wicd is too limited in functionality. -
> GNOME upstream developers embraced NetworkManager as an external
> dependency and seamlessly integrated them into various parts of the
> desktop.

Some users desire precisaly this: static (thus, trustable) network 
configuration.
> 
> better integration / software being network-aware
> =
> - on/offline detection: GNOME relies on NetworkManager's D-Bus messages to
>   establish if the system has a working network connection or not, and how
> to behave in either case.  Applications like Evolution or Empathy will
> only try to fetch mail if NM says there's an appropriate network link,
> avoiding errors like "Could not connect to IMAP server". Epiphany will
> enable offline mode automatically, etc.
> - PackageKit will avoid costly downloads when you're on 3G setting up new
>   connections is easy
> - integration into gnome-control-center
> - setting up a new wireless connection requires a single click via
> prominent integration into GNOME Shell

Precisely the point (within pidgin) that led me to remove NM.
> 
> upgrade problem
> ===
> - NetworkManager was first introduced in lenny, the first release
> installing recommends by default.
> - network-manager-gnome was added a Recommends to the "gnome" meta-package
> in lenny.
> - misuse of Recommends was a widespread problem in lenny, so quite a few
> users disabled Recommends back then.
> - NetworkManager 0.6 in lenny was very limited, e.g. only supported DHCP.
> It is not comparable with the version we shi

Bug#688772: gnome Depends network-manager-gnome

2012-11-13 Thread Andreas Barth

Hi,

* Jordi Mallach (jo...@debian.org) [121113 10:29]:
> [...]

First of all, thanks for your mail. I think it shows a good direction
to move on (though I'm not convinced that not running n-m is more
appropriate than not installing it, but well, YMMV.)


> NetworkManager and static interface configurations
> ==
> 
> Some of the concerns raised in the discussion revolve about the
> possibility of NetworkManager starting in the middle of an upgrade and
> taking over a statically configured interface in /etc/network/interfaces.
> We don't think there's much discussion about that: if that happens, it's a
> critical RC bug that needs to be fixed. The same already applies to
> regressions network drivers in the kernel, libc6 or other basic core
> components which could break a remote Debian dist-upgrade.

Good. I think I can remember that happening times ago, but if you are
convinced it doesn't happen anymore (and we all agree it would be RC),
that's fine then. (JFTR, many if not all of the features about n-m
being integrated into gnome wouldn't be relevant for remote systems.)



> If the details of the technical implementation of this solution aren't
> considered out of scope for this bug report and the CTTE, we are happy to
> discuss a more detailed plan.

I'm interessted in the details insofar as we need to be reasonably
sure the intended solution works. If there is appropriate buy-in from
the relevant maintainers, that would be enough.

Now for wheezy, what do you propose short-term? Otherwise, we might be
in a position where the only options are to demote the depends to
recommends, or to enforce the current n-m configuration - both choices
have consequences I won't like.


Andi


-- 
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/20121113184011.gn26...@mails.so.argh.org

Bug#688772: gnome Depends network-manager-gnome

2012-11-13 Thread Ian Jackson

Jordi Mallach writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> The Debian GNOME team is well aware of the discussion regarding
> #688772,

Thanks for your mail.  (I have bounced it to the bug report - all
discussions on TC issues should be sent to the bug, rather than
directly to the TC list.)

> multiple connection managers problem
> 
> 
> One of the real issues when NM is a Depend of the meta-packages is that it
> violated the principle of "do no harm" when being installed on a system
> which already has a connection manager (such as wicd or less commonly
> connman). While this is not a problem specific to NM (installing wicd on
> an NM system causes the same problem), the problem is of course triggered
> by the Depend in the gnome meta package.

Right.  I think this is the key problem.

> Solving this issue properly will not only make the biggest issues seen with
> gnome depending on NM go away, but will also improve Debian as a whole, which
> is of course always worthwhile.
> 
> The best solution we can currently propose for this issue is to add some
> maintainer script logic to present a debconf prompt (similar to how we
> currently manage multiple display managers like gdm and kdm which can be
> installed at the same time). To avoid unnecessary debconf prompts, the
> debconf prompt would only be shown if such a "conflict" situation is
> detected.

I believe the difference between Depends and Recommends in gnome is
relevant only for existing systems which do not currently have n-m
installed.  Is that your understanding too ?  Such systems presumably
already have some other mechanism for configuring the network.

On such a system installing n-m and then detecting the conflict and
disabling n-m has some obvious technical disadvantages compared to
simply leaving n-m uninstalled: there is a need for additional
scripting, which may have bugs, and perhaps additional debconf
prompts.

Presumably you believe there are technical advantages of installing
n-m but disabling it, compared to simply leaving n-m uninstalled.  But
I'm afraid I still don't understand what they are.  Can you please
explain them to me ?

> Michael has done a proof of concept implementation [1] which is one step
> in that direction, by simply having NM provide a prompt when it detects
> that the wicd binary is installed. A more full implemenation would of
> course require modifications to the wicd package (and connman) as well.

I'm assuming that you would intended this for jessie, not wheezy ?

Thanks,
Ian.


-- 
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/20642.11187.582717.618...@chiark.greenend.org.uk

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-13 Thread Jordi Mallach

Hi,

The Debian GNOME team is well aware of the discussion regarding #688772, which
unfortunately went down an unconstructive path. As such we thought it best
to step back for a little bit to try and formulate our position more clearly
and see if we could find a constructive way to get out of this mess.
Luckily the last few mails on the thread by Don Armstrong and Michael Biebl
already showed there was some light at the end of the tunnel :)

First of all, we want to make clear that the position Joss has been defending
on this exhausting thread is shared by most, if not all, of the Debian GNOME
team members. In other words, we all consider NM an important and integral part
of the desktop system we're delivering, and its absence does degrade its
operation in such a way we find inacceptable.

It is worth to point out that GNOME 3 as we will get in wheezy is a big
departure from the GNOME 2 as delivered in lenny. Among other things GNOME now
strives for a tightly integrated desktop, with NM being a core part of this
desktop. In the opinion of the GNOME team the intended GNOME experience can
only be delivered when all these tightly integrated parts are used together.

Network manager is  not an arbitrary requirement, even if GNOME Shell can
currently run without it. NetworkManager allows GNOME to:
- access all present and commonly used networking technologies (VPN, Wireless,
  3G) via an integrated, very prominent icon in the main desktop bar.
- networking needs have changed over the past years and has become much more
  dynamic and diverse. Connecting to the internet via wireless, 3G or VPN
  should be painless and easy. It should work out of the box and require a
  minimum of fuss.
- only NetworkManager currently offers this kind of features, ifupdown is too
  static/cumbersome to setup, wicd is too limited in functionality.
- GNOME upstream developers embraced NetworkManager as an external dependency
  and seamlessly integrated them into various parts of the desktop.

better integration / software being network-aware
=
- on/offline detection: GNOME relies on NetworkManager's D-Bus messages to
  establish if the system has a working network connection or not, and how to
  behave in either case.  Applications like Evolution or Empathy will only try
  to fetch mail if NM says there's an appropriate network link, avoiding errors
  like "Could not connect to IMAP server". Epiphany will enable offline mode
  automatically, etc.
- PackageKit will avoid costly downloads when you're on 3G setting up new
  connections is easy
- integration into gnome-control-center
- setting up a new wireless connection requires a single click via prominent
  integration into GNOME Shell

upgrade problem
===
- NetworkManager was first introduced in lenny, the first release installing
  recommends by default.
- network-manager-gnome was added a Recommends to the "gnome" meta-package in
  lenny.
- misuse of Recommends was a widespread problem in lenny, so quite a few users
  disabled Recommends back then.
- NetworkManager 0.6 in lenny was very limited, e.g. only supported DHCP. It is
  not comparable with the version we ship in wheezy.

NetworkManager and static interface configurations
==

Some of the concerns raised in the discussion revolve about the
possibility of NetworkManager starting in the middle of an upgrade and
taking over a statically configured interface in /etc/network/interfaces.
We don't think there's much discussion about that: if that happens, it's a
critical RC bug that needs to be fixed. The same already applies to
regressions network drivers in the kernel, libc6 or other basic core
components which could break a remote Debian dist-upgrade.

multiple connection managers problem


One of the real issues when NM is a Depend of the meta-packages is that it
violated the principle of "do no harm" when being installed on a system
which already has a connection manager (such as wicd or less commonly
connman). While this is not a problem specific to NM (installing wicd on
an NM system causes the same problem), the problem is of course triggered
by the Depend in the gnome meta package.

Solving this issue properly will not only make the biggest issues seen with
gnome depending on NM go away, but will also improve Debian as a whole, which
is of course always worthwhile.

The best solution we can currently propose for this issue is to add some
maintainer script logic to present a debconf prompt (similar to how we
currently manage multiple display managers like gdm and kdm which can be
installed at the same time). To avoid unnecessary debconf prompts, the
debconf prompt would only be shown if such a "conflict" situation is
detected.

Michael has done a proof of concept implementation [1] which is one step
in that direction, by simply having NM provide a prompt when it detects
that the w

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-12 Thread Bdale Garbee

Neil McGovern  writes:

> Not commenting on the proposal, but in general I would advise on setting
> the severity of the bug, not if it is RC or not.

I agree.  Actual release criticality is for the release team to decide.

Bdale


pgpgEzmBNaHG9.pgp
Description: PGP signature

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-12 Thread Neil McGovern

On Fri, Nov 09, 2012 at 06:41:08PM +, Ian Jackson wrote:
>While n-m remains a Depends of gnome or gnome-core, any bug report
>from a user that installing n-m broke their system's networking is
>to be treated by the gnome and network-manager maintainers as a
>valid, release-critical, bug.
> 

Not commenting on the proposal, but in general I would advise on setting
the severity of the bug, not if it is RC or not.

Neil
-- 


signature.asc
Description: Digital signature

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-11 Thread Tollef Fog Heen

]] Don Armstrong 

> On Sat, 10 Nov 2012, Tollef Fog Heen wrote:
> > Then I would suggest saying that in the resolution, rather than
> > singling out NM here.
> 
> I think it does ("While n-m remains a Depends of gnome or
> gnome-core"), but feel free to point out clearer wording.

«Any bug report against any package whose installation causes their
networking to be broken is to be treated valid and release critical by
the maintainers and the release team.  This only applies to packages
which are pulled in because of a user request to install a package whose
primary purpose is something else than to pull in aforementioned
package.»

The language can probably be cleaned up a bit.

I also think it's a bad idea, since you're saying that even invalid bug
reports («$USER made dpkg into a shell script that reconfigures the
network if the package installed is NM → RC bug in NM») are valid.  I
don't actually think that's your intention.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

--
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/87obj3cle0@qurzaw.varnish-software.com

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-11 Thread Don Armstrong

On Sat, 10 Nov 2012, Tollef Fog Heen wrote:
> Then I would suggest saying that in the resolution, rather than
> singling out NM here.

I think it does ("While n-m remains a Depends of gnome or
gnome-core"), but feel free to point out clearer wording.


Don Armstrong

-- 
NASCAR is a Yankee conspiracy to keep you all placated so the South
won't rise again.
 -- http://www.questionablecontent.net/view.php?comic=327

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121112004447.gb5...@teltox.donarmstrong.com

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-10 Thread Tollef Fog Heen

]] Don Armstrong 

> On Sat, 10 Nov 2012, Tollef Fog Heen wrote:
> > ]] Ian Jackson 
> > > Perhaps a better approach would be this, post-wheezy:
> > > 
> > >While n-m remains a Depends of gnome or gnome-core, any bug report
> > >from a user that installing n-m broke their system's networking is
> > >to be treated by the gnome and network-manager maintainers as a
> > >valid, release-critical, bug.
> > 
> > It seems NM is being singled out here, but I think if you apply that
> > standard to NM, it should apply to _all_ tools, not just NM.
> 
> The primary difference is that none of the other tools have become a
> dependency of something else. They are at most recommended.

Then I would suggest saying that in the resolution, rather than singling
out NM here.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87mwypci37@xoog.err.no

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-10 Thread Don Armstrong

On Sat, 10 Nov 2012, Tollef Fog Heen wrote:
> ]] Ian Jackson 
> > Perhaps a better approach would be this, post-wheezy:
> > 
> >While n-m remains a Depends of gnome or gnome-core, any bug report
> >from a user that installing n-m broke their system's networking is
> >to be treated by the gnome and network-manager maintainers as a
> >valid, release-critical, bug.
> 
> It seems NM is being singled out here, but I think if you apply that
> standard to NM, it should apply to _all_ tools, not just NM.

The primary difference is that none of the other tools have become a
dependency of something else. They are at most recommended.


Don Armstrong

-- 
"There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence."
 -- Jeremy S. Anderson

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121110193706.gh11...@teltox.donarmstrong.com

Re: Bug#688772: gnome Depends network-manager-gnome

2012-11-10 Thread Tollef Fog Heen

]] Ian Jackson 

> Perhaps a better approach would be this, post-wheezy:
> 
>While n-m remains a Depends of gnome or gnome-core, any bug report
>from a user that installing n-m broke their system's networking is
>to be treated by the gnome and network-manager maintainers as a
>valid, release-critical, bug.

It seems NM is being singled out here, but I think if you apply that
standard to NM, it should apply to _all_ tools, not just NM.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87bof5e0pg@xoog.err.no

Bug#688772: gnome Depends network-manager-gnome

2012-11-09 Thread Don Armstrong

On Fri, 09 Nov 2012, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > This is only the case if we are convinced the NM maintainer(s) are
> > acting in bad faith. While that's certainly a possibility, we
> > shouldn't assume it.
>
> If I were in the position of the gnome maintainers here (ie if I
> were the one being overruled) I would be making exactly the same
> point.

The NM maintainer(s) aren't the same as the set of gnome maintainers,
though. [Even though there is some overlap and certainly communication
between them.]

> > 1. NM must not break an existing working networking configuration.
> 
> Is this possible ? I mean, I worry that interpreted broadly ("_any_
> existing ...") this would simply mean that n-m should never do
> anything.
>
> Perhaps a better approach would be this, post-wheezy:
> 
>While n-m remains a Depends of gnome or gnome-core, any bug report
>from a user that installing n-m broke their system's networking is
>to be treated by the gnome and network-manager maintainers as a
>valid, release-critical, bug.
> 
> We should ask the n-m maintainer to comment on this proposal. If
> they think it's unworkable then that amounts to a statement that it
> will not be possible to reliably identify, and fix, all such
> problems.

Ok. I believe having Michael Biebl and/or the rest of the NM team
weigh in on this issue will be useful.


Don Armstrong

-- 
"For those who understand, no explanation is necessary.
 For those who do not, none is possible."

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121109190658.gi11...@rzlab.ucr.edu

Bug#688772: gnome Depends network-manager-gnome

2012-11-09 Thread Ian Jackson

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 09 Nov 2012, Ian Jackson wrote:
> > This for me is the critical point. Can _anyone_ provide a coherent
> > and fact-based explanation for why this is a good idea ?
> 
> NM is apparently required for various parts of gnome to figure out
> whether it is online or offline. It's also necessary for the network
> configuration components to work properly inside of gnome.

My understanding is that if you have n-m not installed, you get the
same or better experience than if you have n-m installed but not
running.

Of course if you are not using n-m to manage your network then the
network configuration components inside gnome are not going to work
properly.  That's part of the price you pay for not using n-m.  But
this is true whether n-m is not installed, or installed but disabled.

I'm sure somene will correct me if I'm wrong.

> > Secondly, there is a process/approval problem here for the
> > post-wheezy case. I think this resolution text effectively neuters
> > itself after wheezy since AIUI the n-m maintainers naturally think
> > that all the concerns are _already_ satisfactorily addressed.
> 
> This is only the case if we are convinced the NM maintainer(s) are
> acting in bad faith. While that's certainly a possibility, we
> shouldn't assume it.

I don't think that my complaint here involves assuming bad faith on
the part of the gnome maintainers.  It simply doesn't make any sense
to ask them to do further work to resolve these problems to their
satisfaction, when in their view insofar as there are problems they
are already satisfactorily resolved.

If I were in the position of the gnome maintainers here (ie if I were
the one being overruled) I would be making exactly the same point.

> Perhaps specifically spelling out what the
> technical requirements are would be sufficient to mitigate the
> potential for the appearance of bad faith. Such as:

I want to reiterate that I don't think this problem involves supposing
any bad faith.  It's that since we disagree with the maintainers about
the requirements and are overruling them, asking them to set the
requirements does not make sense and is inviting misunderstanding.

> 1. NM must not break an existing working networking configuration.

Is this possible ?  I mean, I worry that interpreted broadly ("_any_
existing ...") this would simply mean that n-m should never do
anything.

Perhaps a better approach would be this, post-wheezy:

   While n-m remains a Depends of gnome or gnome-core, any bug report
   from a user that installing n-m broke their system's networking is
   to be treated by the gnome and network-manager maintainers as a
   valid, release-critical, bug.

We should ask the n-m maintainer to comment on this proposal.  If they
think it's unworkable then that amounts to a statement that it will
not be possible to reliably identify, and fix, all such problems.

Ian.

-- 
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/20637.20036.446268.685...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-11-09 Thread Don Armstrong

On Fri, 09 Nov 2012, Ian Jackson wrote:
> This for me is the critical point. Can _anyone_ provide a coherent
> and fact-based explanation for why this is a good idea ?

NM is apparently required for various parts of gnome to figure out
whether it is online or offline. It's also necessary for the network
configuration components to work properly inside of gnome.

There may be additional technical problems that not having NM causes
gnome, but they haven't been adequately communicated. [However,
Michael Biebl is planning on communicating them in an e-mail to us
shortly.]

> The biggest technical downside is that this approach doesn't solve
> the upgrade problem without a good deal of complicated machinery to
> try to determine whether the system should pretend that n-m isn't
> installed (or annoying prompts, or something).

This machinery should be in place even without the upgrade process
just to avoid breakage when multiple elements of the NM, wicd, and
conntrack set are installed.

> Secondly, there is a process/approval problem here for the
> post-wheezy case. I think this resolution text effectively neuters
> itself after wheezy since AIUI the n-m maintainers naturally think
> that all the concerns are _already_ satisfactorily addressed.

This is only the case if we are convinced the NM maintainer(s) are
acting in bad faith. While that's certainly a possibility, we
shouldn't assume it. Perhaps specifically spelling out what the
technical requirements are would be sufficient to mitigate the
potential for the appearance of bad faith. Such as:

1. NM must not break an existing working networking configuration.

2. In the event that a networking configuration manger which is unable
to cooperate with NM is previously installed, NM should default to
disabling itself. [With possibilities for debconf prompting at low
priority to change it, I suspect.]

> Alternatively, if it's intended that after wheezy the maintainers
> will do whatever they feel appropriate then the resolution should
> explicitly limit the scope of the overruling to wheezy and have a
> new advisory paragraph for the post-wheezy case. (I mention this for
> completeness; I wouldn't agree with that approach.)

I don't agree with this approach either, because the technical
concerns are the entire reason why we're here.

Don Armstrong

-- 
This can't be happening to me. I've got tenure.
 -- James Hynes _Publish and Perish_

http://www.donarmstrong.com  http://rzlab.ucr.edu

-- 
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/20121109180910.gg11...@rzlab.ucr.edu

Bug#688772: gnome Depends network-manager-gnome

2012-11-09 Thread Andreas Barth

* Ian Jackson (ijack...@chiark.greenend.org.uk) [121109 10:51]:
> There is no technical reason to prefer a situation where the user has
> n-m installed but disabled to one where they don't have it installed.
> 
> There _are_ technical reasons why (on systems where n-m's operation
> is not desired) not installing it is better.

While I agree with you on the technical part, however, there is a
difference: We are not asked "what is the technical best solution",
but "please overrule the decision of the gnome maintainers". If it
would be the first question, I'd tend to agree with not setting a
depends. However, it isn't. And I don't think the situation with "nm
isn't start" is still so bad that it warrants an overruling of the
maintainers. (With my normal DD hat on, I think I'd prefer to not have
n-m installed via gnome, but well - that's not the question at hand.)


> The biggest technical downside is that this approach doesn't solve the
> upgrade problem without a good deal of complicated machinery to try to
> determine whether the system should pretend that n-m isn't installed
> (or annoying prompts, or something).

That has to be fixed, yes. It might be helpful to put a few more
things into the resolution to give examples what needs to be fixed.


> Secondly, there is a process/approval problem here for the post-wheezy
> case.

Same here - I'm happy for whatever useful process to be put into it. I
however think once a dist-upgrade installing n-m could be done without
it getting active without jumping through loops (or: disturbing
otherwise setup network interfaces) we shouldn't force the maintainers
to not set a depends.



Andi


-- 
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/20121109112723.gm26...@mails.so.argh.org

Bug#688772: gnome Depends network-manager-gnome

2012-11-09 Thread Ian Jackson

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> B 4. We overrule the decision of the meta-gnome maintainers to add a
> Bdependency from gnome to network-manager-gnome; this dependency
> Bshould be [-removed for the release of wheezy. After the release of
> Bwheezy, if-] {+removed. If+} in the opinion of the NM maintainer {+(and
> Bbefore the release of wheezy the Release Managers)+} the concerns
> Braised in §4 of the CTTE decision #681834 have been addressed
> Bthrough technical [-means,-] {+means (e.g. by preventing the starting of 
> NM as
> Bdiscussed in #688772),+} the meta-gnome maintainers may freely
> Badjust the dependencies as usual.

Obviously we should have this on the ballot if other TC members want
it.

But I am opposed to it because:


Firstly, and most importantly:

There is no technical reason to prefer a situation where the user has
n-m installed but disabled to one where they don't have it installed.

There _are_ technical reasons why (on systems where n-m's operation
is not desired) not installing it is better.

This for me is the critical point.  Can _anyone_ provide a coherent
and fact-based explanation for why this is a good idea ?  (And I mean
why this is a _technically_ good idea.  "It might help placate the
maintainers" is not a technical reason.)

The biggest technical downside is that this approach doesn't solve the
upgrade problem without a good deal of complicated machinery to try to
determine whether the system should pretend that n-m isn't installed
(or annoying prompts, or something).


Secondly, there is a process/approval problem here for the post-wheezy
case.  I think this resolution text effectively neuters itself after
wheezy since AIUI the n-m maintainers naturally think that all the
concerns are _already_ satisfactorily addressed.  If the n-m
maintainers felt that the concerns of n-m sceptics _weren't_
satisfactorily addressed _already_ they would surely not be pushing
n-m so hard right now.

So this is likely to result in the n-m maintainers engaging in some
kind of make-work (which both they and n-m sceptics consider futile)
to try to comply with a ruling which they don't agree with but which
delegates part of the decision back to them.  And then, when the
make-work turns out not to satisfy, further escalation and bad
feeling.

If we are overruling the maintainer we should not ask them to be the
judge of whether their fix is sufficient.  We should either make the
requirements objective, or nominate someone else to make the decision.

Alternatively, if it's intended that after wheezy the maintainers will
do whatever they feel appropriate then the resolution should
explicitly limit the scope of the overruling to wheezy and have a new
advisory paragraph for the post-wheezy case.  (I mention this for
completeness; I wouldn't agree with that approach.)


Ian.


--
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/20636.53495.550905.990...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-11-09 Thread Ian Jackson

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> That makes sense. I've adjusted it as follows, putting the RMs in the
> position of gatekeeper. I would be ok with changing that to a
> delegated member of the CTTE or someone else if the RMs didn't want to
> be the final gatekeepers here. (git 07402)

We should certainly ask the RMs first!  If I were them I wouldn't want
to be, for example, accused of being part of a crusade.

Ian.


-- 
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/20636.52034.442808.650...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-11-08 Thread Don Armstrong

On Thu, 08 Nov 2012, Andreas Barth wrote:
> I'm thinking whether it might be helpful to put a reference to the
> discussion here, like "e.g. by preventing nm to start as discussed
> in #688772".
> 
> Also, with my tech ctte member hat on, I don't think I mind to have
> the technical fixes applied pre-wheezy (however it might be useful to
> have someone additionally to the nm maintainer in the loop to avoid
> further misunderstandings, at least pre-wheezy). (I however fear it is
> too late, so I'm not sure we should put something in about the
> pre-wheezy.)

That makes sense. I've adjusted it as follows, putting the RMs in the
position of gatekeeper. I would be ok with changing that to a
delegated member of the CTTE or someone else if the RMs didn't want to
be the final gatekeepers here. (git 07402)

B 4. We overrule the decision of the meta-gnome maintainers to add a
Bdependency from gnome to network-manager-gnome; this dependency
Bshould be [-removed for the release of wheezy. After the release of
Bwheezy, if-] {+removed. If+} in the opinion of the NM maintainer {+(and
Bbefore the release of wheezy the Release Managers)+} the concerns
Braised in §4 of the CTTE decision #681834 have been addressed
Bthrough technical [-means,-] {+means (e.g. by preventing the starting of 
NM as
Bdiscussed in #688772),+} the meta-gnome maintainers may freely
Badjust the dependencies as usual.

Don Armstrong

-- 
Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250

http://www.donarmstrong.com  http://rzlab.ucr.edu

--
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/20121108220504.gd11...@rzlab.ucr.edu

Bug#688772: gnome Depends network-manager-gnome

2012-11-08 Thread Andreas Barth

* Don Armstrong (d...@debian.org) [121108 01:18]:
> Therefore
> 
> A 4. We overrule the decision of the meta-gnome maintainers to add a
> Adependency from gnome to network-manager-gnome; this dependency
> Ashould be removed for the release of wheezy.
> 
> B 4. We overrule the decision of the meta-gnome maintainers to add a
> Bdependency from gnome to network-manager-gnome; this dependency
> Bshould be removed for the release of wheezy. After the release of
> Bwheezy, if in the opinion of the NM maintainer the concerns
> Braised in §4 of the CTTE decision #681834 have been addressed
> Bthrough technical means, the meta-gnome maintainers may freely
> Badjust the dependencies as usual.

I'm thinking whether it might be helpful to put a reference to the
discussion here, like "e.g. by preventing nm to start as discussed in
#688772".

Also, with my tech ctte member hat on, I don't think I mind to have
the technical fixes applied pre-wheezy (however it might be useful to
have someone additionally to the nm maintainer in the loop to avoid
further misunderstandings, at least pre-wheezy). (I however fear it is
too late, so I'm not sure we should put something in about the
pre-wheezy.)


Andi


-- 
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/20121108214617.gl26...@mails.so.argh.org

Bug#688772: gnome Depends network-manager-gnome

2012-11-07 Thread Raphael Hertzog

Hi,

On Fri, 26 Oct 2012, Michael Biebl wrote:
> This would also help in situations where users install both wicd and
> network-manager by accident, which usually doesn't really work well
> since e.g. both spawn their own instance of wpa_supplicant.
> 
> A more detailed reply will follow soon.

I haven't seen this more detailed reply, or did I miss something?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


--
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/20121108073506.gc30...@x230-buxy.home.ouaza.com

Bug#688772: gnome Depends network-manager-gnome

2012-11-07 Thread Don Armstrong

On Tue, 30 Oct 2012, Don Armstrong wrote:
> On Fri, 26 Oct 2012, Michael Biebl wrote:
> > One idea that came up was to check wether wicd is in use (or for
> > that matter ifupdown), and then show a debconf prompt explaining
> > the situation, and letting the user chose if he wants to take over
> > network management by NetworkManager. It would work similar to how
> > we currently handle multiple installed display managers, like gdm3
> > or kdm (btw, gdm3 is currently a hard depends of gnome-core). If
> > the users choses no, we could disable the service via update-rc.d
> > disable, so the invoke-rc.d later on in postinst would not start
> > NM.
> 
> I believe some solution along this line which mitigates breakage
> caused by the co-installation of wicd and NM would go a long way to
> resolve the technical concerns of having gnome depend on NM.[0]
> 
> I'm concerned that such a solution won't be ready, tested, and
> accepted in time for wheezy, however. But I can certainly see
> proposing an option to have an explicit sunset on the CTTE's
> requirement for gnome to only recommend NM once this work is done.[1]

I've gone ahead and drafted a B option which does this (attached).
I've also made an explicit request for a release note documenting that
people using gnome should (re)consider using NM. [That still requires
someone to "do the work", of course.]

I'd like to get some more input on this, and then call for a vote
sometime this week if at all possible.

Don Armstrong

-- 
LEADERSHIP -- A form of self-preservation exhibited by people with
autodestructive imaginations in order to ensure that when it comes to
the crunch it'll be someone else's bones which go crack and not their
own. 
 -- The HipCrime Vocab by Chad C. Mulligan 
(John Brunner _Stand On Zanzibar_ p256-7)

http://www.donarmstrong.com  http://rzlab.ucr.edu
1. The TC notes the decision of the meta-gnome maintainers to
   implement the TC decision in #681834 by:
(a) softening the dependency in the gnome-core metapackage
from Depends to Recommends, as required
(b) adding a new dependency in the gnome metapackage,
as a Depends.  (In squeeze, this is where the dependency
was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheezy.

3. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

A 4. We overrule the decision of the meta-gnome maintainers to add a
Adependency from gnome to network-manager-gnome; this dependency
Ashould be removed for the release of wheezy.

B 4. We overrule the decision of the meta-gnome maintainers to add a
Bdependency from gnome to network-manager-gnome; this dependency
Bshould be removed for the release of wheezy. After the release of
Bwheezy, if in the opinion of the NM maintainer the concerns
Braised in §4 of the CTTE decision #681834 have been addressed
Bthrough technical means, the meta-gnome maintainers may freely
Badjust the dependencies as usual.

5. We request that the Release Team unblock update(s) to meta-gnome so
   that our decisions may be implemented in wheezy.

6. We request that a release note is created explaining that gnome
   users who do not currently have NM installed consider installing
   it.

Bug#688772: gnome Depends network-manager-gnome

2012-10-30 Thread Don Armstrong

On Fri, 26 Oct 2012, Michael Biebl wrote:
> I've been discussing with jordi today about this issue.

Thanks for working on this.

> One idea that came up was to check wether wicd is in use (or for
> that matter ifupdown), and then show a debconf prompt explaining the
> situation, and letting the user chose if he wants to take over
> network management by NetworkManager. It would work similar to how
> we currently handle multiple installed display managers, like gdm3
> or kdm (btw, gdm3 is currently a hard depends of gnome-core). If the
> users choses no, we could disable the service via update-rc.d
> disable, so the invoke-rc.d later on in postinst would not start NM.

I believe some solution along this line which mitigates breakage
caused by the co-installation of wicd and NM would go a long way to
resolve the technical concerns of having gnome depend on NM.[0]

I'm concerned that such a solution won't be ready, tested, and
accepted in time for wheezy, however. But I can certainly see
proposing an option to have an explicit sunset on the CTTE's
requirement for gnome to only recommend NM once this work is done.[1]

> This would also help in situations where users install both wicd and
> network-manager by accident, which usually doesn't really work well
> since e.g. both spawn their own instance of wpa_supplicant.

Right. It would be awesome to have some kind of coordination between
NM and wicd (and anything else which potentially configures the
network in a conflicting way) so that they both present a similar
dialog box if the other is installed.


Don Armstrong

0: Indeed, I would have much rather seen this than what I proposed
previously in B, but as it requires substantial work on both your and
the wicd maintainers' parts, it's not something that the CTTE can
require.

1: Even though I personally don't think it's the right approach for
gnome to Depend on NM, it would no longer cause the technical problems
which make such a Dependency problematic enough for the CTTE to take
action.
-- 
A kiss was mysterious and powerful, fragile and invincible. Like any
spark, a kiss might fizzle into nothing or consume an entire forest.
[...] A kiss could change the entire world.
  -- Scott Westerfeld _The Killing of Worlds_ p336

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121030211204.gi11...@rzlab.ucr.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-26 Thread Don Armstrong

On Fri, 26 Oct 2012, Chris Knadle wrote:
> I think this effectively reduces down to checking if N-M is already
> installed and prompting if it's not.

That means that you would prompt on any new NM install, which means
yet another box that users have to click/press enter through. That's a
ton of additional work for users, with the added possibility of users
getting the option wrong and ending up with NM not handling their
networking for some obscure Debian-specific reason. It's not like the
set of configurations where NM probably shouldn't be run is that big.

Don Armstrong

-- 
The computer allows you to make mistakes faster than any other
invention, with the possible exception of handguns and tequila
 -- Mitch Ratcliffe

http://www.donarmstrong.com  http://rzlab.ucr.edu

-- 
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/20121026170222.gk11...@rzlab.ucr.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-26 Thread Chris Knadle

On Thursday, October 25, 2012 18:27:58, Michael Biebl wrote:
> On 25.10.2012 22:47, Andreas Barth wrote:
> > * Jeremy Bicha (jbi...@ubuntu.com) [121025 18:51]:
> >> On 25 October 2012 12:17, Don Armstrong  wrote:
> >>> That said, if I'm wrong, and you believe that there is a compromise
> >>> which would resolve the concerns raised beyond those already presented
> >>> (status quo with/without release notes), now would be the time to
> >>> present it.
> >> 
> >> My proposal is to:
> >> 1. Add a paragraph to the Release Notes with the one line command
> >> people should use if they don't want NetworkManager running:
> >> "update-rc.d disable network-manager"
> >> 2. And cases where that doesn't work are RC.
> > 
> > How would that prevent startup of n-m during upgrades from stable to
> > next-stable?  (Which could already present issues, especially if the
> > system is remote managed)
> 
> I've been discussing with jordi today about this issue.
>
> One idea that came up was to check wether wicd is in use (or for that
> matter ifupdown), and then show a debconf prompt explaining the
> situation, and letting the user chose if he wants to take over network
> management by NetworkManager.
> It would work similar to how we currently handle multiple installed
> display managers, like gdm3 or kdm (btw, gdm3 is currently a hard
> depends of gnome-core).
> If the users choses no, we could disable the service via update-rc.d
> disable, so the invoke-rc.d later on in postinst would not start NM.
> 
> This would also help in situations where users install both wicd and
> network-manager by accident, which usually doesn't really work well
> since e.g. both spawn their own instance of wpa_supplicant.
> 
> A more detailed reply will follow soon.

This is a good suggestion, and one which I think would work around all of the 
breakage concerns I raised on this issue.  Thank you for putting in the effort 
for coming up with this option.

A tweak I'd suggest considering would be to reverse the logic of the test of 
when to show the debconf prompt -- because there are several possible tools 
for setting up networking like iwconfig, manually using wpa_supplicant, 
commands in rc.local, etc, such that trying to test for all of the specific 
situations of when to show the option might be frustrating to track down 
competely.  What we /do/ know is that there are two known situations where the 
user does /not/ need to see the choice to disable N-M, which is

   A) when N-M is already installed and running, or
   B) when N-M is installed but disabled via update-rc.d

I think this effectively reduces down to checking if N-M is already installed 
and prompting if it's not.  Well, unless you also want to test if it's running 
to take into consideration the possibility that N-M could be locally installed 
outside of package management, in which also installing N-M as a package would 
be... weird.  ;-)

The last thing I'm wondering about are the concerns from the Gnome team about 
whether empathy or evolution would know if you're online -- which in this case 
means if they do if N-M is installed but not running.  If they do then this 
solution would have that as an advantage.  If it doesn't then (at least on the 
surface) this solution seems similar to N-M being a Recommends in the meta-
gnome package such that it doesn't have to be installed.  [I'm not bringing 
this up as an argument against choosing this solution because I think the 
solution would work, but rather I'm trying to objectively evaluate what the 
effect this solution would have and how it compares to other possibilities.]

Thanks again.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

signature.asc
Description: This is a digitally signed message part.

Bug#688772: gnome Depends network-manager-gnome

2012-10-25 Thread Michael Biebl

On 25.10.2012 22:47, Andreas Barth wrote:
> * Jeremy Bicha (jbi...@ubuntu.com) [121025 18:51]:
>> On 25 October 2012 12:17, Don Armstrong  wrote:
>>> That said, if I'm wrong, and you believe that there is a compromise
>>> which would resolve the concerns raised beyond those already presented
>>> (status quo with/without release notes), now would be the time to
>>> present it.
>>
>> My proposal is to:
>> 1. Add a paragraph to the Release Notes with the one line command
>> people should use if they don't want NetworkManager running:
>> "update-rc.d disable network-manager"
>> 2. And cases where that doesn't work are RC.
> 
> How would that prevent startup of n-m during upgrades from stable to
> next-stable?  (Which could already present issues, especially if the
> system is remote managed)

I've been discussing with jordi today about this issue.

One idea that came up was to check wether wicd is in use (or for that
matter ifupdown), and then show a debconf prompt explaining the
situation, and letting the user chose if he wants to take over network
management by NetworkManager.
It would work similar to how we currently handle multiple installed
display managers, like gdm3 or kdm (btw, gdm3 is currently a hard
depends of gnome-core).
If the users choses no, we could disable the service via update-rc.d
disable, so the invoke-rc.d later on in postinst would not start NM.

This would also help in situations where users install both wicd and
network-manager by accident, which usually doesn't really work well
since e.g. both spawn their own instance of wpa_supplicant.

A more detailed reply will follow soon.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

signature.asc
Description: OpenPGP digital signature

Bug#688772: gnome Depends network-manager-gnome

2012-10-25 Thread Andreas Barth

* Jeremy Bicha (jbi...@ubuntu.com) [121025 18:51]:
> On 25 October 2012 12:17, Don Armstrong  wrote:
> > That said, if I'm wrong, and you believe that there is a compromise
> > which would resolve the concerns raised beyond those already presented
> > (status quo with/without release notes), now would be the time to
> > present it.
> 
> My proposal is to:
> 1. Add a paragraph to the Release Notes with the one line command
> people should use if they don't want NetworkManager running:
> "update-rc.d disable network-manager"
> 2. And cases where that doesn't work are RC.

How would that prevent startup of n-m during upgrades from stable to
next-stable?  (Which could already present issues, especially if the
system is remote managed)



Andi


-- 
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/20121025204701.gk26...@mails.so.argh.org

Bug#688772: gnome Depends network-manager-gnome

2012-10-25 Thread Bdale Garbee

Jeremy Bicha  writes:

> - Why don't they complain about how GNOME3 is significantly different
> than what was shipped in previous Debian releases?

It's not the role of the TC to "complain".  It's our role to resolve
issues that are brought to us for resolution.

> - Why don't they complain about epiphany or iceweasel being a depends
> which affects far more people in a far more visible way? I mean, have
> you looked at what the "gnome" package depends on? evolution,
> gnome-games, gimp, inkscape, rhythmbox, transmission, etc? And "gnome"
> depends on less stuff now than it did for squeeze.

Same as above.

> - Why not a larger discussion about the role of depends in
> metapackages? That discussion is obviously too late for Wheezy but it
> probably should happen well before Jessie is relased.

Actually, I think I *did* suggest that such a discussion would be
appropriate, but clearly this should not be allowed to delay wheezy.

> - Shouldn't working and easy to use wireless (aka NetworkManager) be
> considered part of the basic desktop infrastructure? 

Sure.  I'd like world peace, too, while we're at it!  ;-)

> And users who
> don't like those decisions being made for them shouldn't use "gnome"?

This is indeed one of the reasons that I personally do not use "gnome".

Bdale

pgpe8Fj2AKAdn.pgp
Description: PGP signature

Bug#688772: gnome Depends network-manager-gnome

2012-10-25 Thread Jeremy Bicha

On 25 October 2012 12:17, Don Armstrong wrote:
> That said, if I'm wrong, and you believe that there is a compromise
> which would resolve the concerns raised beyond those already presented
> (status quo with/without release notes), now would be the time to
> present it.

My proposal is to:
1. Add a paragraph to the Release Notes with the one line command
people should use if they don't want NetworkManager running:
"update-rc.d disable network-manager"
2. And cases where that doesn't work are RC.

The advantages of this proposal:
1. Users that don't want NetworkManager messing with their networking
configuration can get it and wouldn't have to worry about babysitting
upgrades or new installs to make sure that NetworkManager isn't pulled
in by some package.
2. Users who've upgraded from Lenny can be sure to have NetworkManager
installed and working, which really is far better for most GNOME users
than anything else. Those that have opted out previously are given an
opportunity to revisit their decision since the circumstances have
changed significantly.
3. Wouldn't require a CTTE resolution
4. Would continue to allow the Debian GNOME Team to manage their
metapackages based on what GNOME says is required and what the team
feel fits best into a standard GNOME desktop.
5. Would not put an implicit duty on the GNOME Team to come before the
CTTE every time they intend to change something in their metapackage
that might make someone annoyed.

The Technical Committee complaining about NetworkManager seems to the
GNOME Team to be a bit misplaced.
- Why don't they complain about how GNOME3 is significantly different
than what was shipped in previous Debian releases?
- Why don't they complain about epiphany or iceweasel being a depends
which affects far more people in a far more visible way? I mean, have
you looked at what the "gnome" package depends on? evolution,
gnome-games, gimp, inkscape, rhythmbox, transmission, etc? And "gnome"
depends on less stuff now than it did for squeeze.
- Why not a larger discussion about the role of depends in
metapackages? That discussion is obviously too late for Wheezy but it
probably should happen well before Jessie is relased.
- Shouldn't working and easy to use wireless (aka NetworkManager) be
considered part of the basic desktop infrastructure? And users who
don't like those decisions being made for them shouldn't use "gnome"?

Jeremy

--
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/caaajcmypbsbmiwttzoktvsavmqf9qayf5guchfewah4f0u8...@mail.gmail.com

Bug#688772: gnome Depends network-manager-gnome

2012-10-25 Thread Ian Jackson

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Thu, 25 Oct 2012, Josselin Mouette wrote:
> > I’m not the one who has violated the Constitution so far. The CTTE, on
> > the other hand, is currently acting in direct violation of Constitution
> > §6.3.6. No discussion was ever attempted after the upload of meta-gnome3
> > 1:3.4+2 which implements the decision for bug#645656.
> 
> It's true that discussion and consensus building should have happened
> before any drafting (even if just as a general courtesy.) However,
> we've been discussing this issue with the attempt to reach consensus
> or at least some understanding for the past month, and still have yet
> to even start to make a technical decision. [Not to mention the fact
> that it stems from an issue which has been discussed extensively for
> the past six months.]

Personally I don't see this as a new issue.  As you say it stems from
the previous issue which seems not to have been fully closed.  An
alternative interpretation would be that I, wearing my "individual"
hat, referred the matter to the TC.  I don't think there's anything in
the constitution preventing a TC member from referring a matter to the
TC.

I think it would have been quite wrong to require one of the original
complainants, or a new complainant, to make an explicit referral to
the TC of what I consider to be the maintainers' failure to
satisfactorily implement the previous TC resolution; or to put it
another way, the failure of the previous TC resolution to explicitly
rule out an undesirable approach which wasn't anticipated in the
previous discussions.

And from a practical point of view, I don't think it would be
reasonable to expect anyone to voluntarily stick their head above the
parapet into the toxic atmosphere surrounding this issue.

Ian.

--
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/20617.27288.740904.424...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-25 Thread Don Armstrong

On Thu, 25 Oct 2012, Josselin Mouette wrote:
> Le jeudi 25 octobre 2012 à 00:13 +0200, Joerg Jaspert a écrit : 
> > On 13009 March 1977, Josselin Mouette wrote:
> > 
> > > In the current situation, I do not feel bound by any decisions the
> > > committee might make.
> > 
> > You know, if it really comes to one more CTTE decision around NM and
> > Gnome, which you don't like - the above is a pretty clean resignation
> > from the project. Which would be a shame - but still, directly violating
> > one of our core documents? Seriously?
> 
> I’m not the one who has violated the Constitution so far. The CTTE, on
> the other hand, is currently acting in direct violation of Constitution
> §6.3.6. No discussion was ever attempted after the upload of meta-gnome3
> 1:3.4+2 which implements the decision for bug#645656.

It's true that discussion and consensus building should have happened
before any drafting (even if just as a general courtesy.) However,
we've been discussing this issue with the attempt to reach consensus
or at least some understanding for the past month, and still have yet
to even start to make a technical decision. [Not to mention the fact
that it stems from an issue which has been discussed extensively for
the past six months.]

That said, if I'm wrong, and you believe that there is a compromise
which would resolve the concerns raised beyond those already presented
(status quo with/without release notes), now would be the time to
present it.

Finally, if you believe the committee to be acting improperly, please
point it out. It's easy for us to either change, or if we disagree in
the interpretation of the constitution, get the secretary to interpret
the constitution for us. [I've gone ahead and put Kurt in the loop so he can 

Don Armstrong

-- 
I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

http://www.donarmstrong.com  http://rzlab.ucr.edu

--
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/20121025161759.gs7...@teltox.donarmstrong.com

Bug#688772: gnome Depends network-manager-gnome

2012-10-25 Thread Josselin Mouette

Hi,

Le jeudi 25 octobre 2012 à 00:13 +0200, Joerg Jaspert a écrit : 
> On 13009 March 1977, Josselin Mouette wrote:
> 
> > In the current situation, I do not feel bound by any decisions the
> > committee might make.
> 
> You know, if it really comes to one more CTTE decision around NM and
> Gnome, which you don't like - the above is a pretty clean resignation
> from the project. Which would be a shame - but still, directly violating
> one of our core documents? Seriously?

I’m not the one who has violated the Constitution so far. The CTTE, on
the other hand, is currently acting in direct violation of Constitution
§6.3.6. No discussion was ever attempted after the upload of meta-gnome3
1:3.4+2 which implements the decision for bug#645656. There is consensus
among the GNOME team that this is the correct course of action, and no
one has requested a decision from the TC apart from Ian himself.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-

--
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/1351156798.3536.403.camel@pi0307572

Bug#688772: gnome Depends network-manager-gnome

2012-10-24 Thread Joerg Jaspert

On 13009 March 1977, Josselin Mouette wrote:

> In the current situation, I do not feel bound by any decisions the
> committee might make.

You know, if it really comes to one more CTTE decision around NM and
Gnome, which you don't like - the above is a pretty clean resignation
from the project. Which would be a shame - but still, directly violating
one of our core documents? Seriously?

-- 
bye, Joerg
 and yes, the ftpmasters are not the most clueful people

-- 
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/87a9vbcycn@gkar.ganneff.de

Bug#688772: gnome Depends network-manager-gnome

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Wed, 24 Oct 2012, Ian Jackson wrote:
> > AIUI the point of introducing wicd was to try to find some kind of
> > compromise. Given the response from the GNOME maintainers, I think
> > it is a bad idea.
> 
> That's correct. I was hoping to find some kind of compromise that
> would satisfy the gnome maintainers' requirement to have NM installed
> by default whilst mitigating breakage.

Right.

(Although I need to quibble with your "by default".  No-one is
suggesting that n-m should not be installed by default.  The gnome
maintainers' requirement is to have n-m installed even when the user
has previously deliberately deinstalled it.)

Ian.


-- 
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/20616.9432.703310.976...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-24 Thread Don Armstrong

On Wed, 24 Oct 2012, Ian Jackson wrote:
> Shockingly, I find myself in agreement with at least some of the
> views of the GNOME maintainers. As I have said, I don't think this
> proposed dependency on wicd makes any kind of sense. It achieves
> neither the objectives of the GNOME maintainers nor the objectives
> of users who have chosen to remove n-m.
> 
> AIUI the point of introducing wicd was to try to find some kind of
> compromise. Given the response from the GNOME maintainers, I think
> it is a bad idea.

That's correct. I was hoping to find some kind of compromise that
would satisfy the gnome maintainers' requirement to have NM installed
by default whilst mitigating breakage.

Since the option appears to have done neither, and I'm not
particularly enamored with it either, I'm going to drop it. [If
someone else feels strongly about having it on the ballot, please feel
free to reintroduce it.]


Don Armstrong

-- 
But if, after all, we are on the wrong track, what then? Only
disappointed human hopes, nothing more. And even if we perish, what
will it matter in the endless cycles of eternity?
 -- Fridtjof Nansen _Farthest North_ p152

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121024171831.gu11...@rzlab.ucr.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-24 Thread Don Armstrong

On Wed, 24 Oct 2012, Josselin Mouette wrote:
> Le mardi 23 octobre 2012 à 15:16 -0700, Don Armstrong a écrit :
> > 2. Our intent, as stated in the rationale section of our previous
> >decision (#681834, paras 3 and 5), is that squeeze users who have
> >gnome installed but not network-manager do not find that
> >network-manager becomes installed when they upgrade to wheezy.
> 
> There lies the real disagreement.
> 
> Our very intent is that squeeze users who have gnome installed but not
> NM *do* find that NM becomes installed when they upgrade to wheezy.
> (Actually we should have done that for the lenny→squeeze upgrade but
> vocal people already won that time.)

What in particular breaks if NM is not installed?[2] I personally
understand that the gnome maintainers want NM to be installed by
default in all but unusual configurations, which is why I even
bothered to draft option B.

> The fact that it could potentially, in very specific to-be-described
> cases, break something, should be documented in the release notes.

This is certainly one approach that could be taken. However, from the
information available to me, the breakage caused by these situations
outweighs the breakage caused by not having NM installed[2] if someone
has chosen to ignore recommends.

> Everything else Ian and you have proposed derives from the fact that
> you want to force NM out.

My only concern is for the users of gnome; I don't have a personal
stake in this race at all. Continuing to ascribe these motivations to
me and Ian is hurtful, and not appropriate. Please stop.

> > B 4. We overrule the decision of the meta-gnome maintainers to add a
> > Bdependency from gnome to network-manager-gnome; this dependency
> > Bshould be replaced with a dependecy on network-manager-gnome (>=
> > B0.9.4) | wicd.
> 
> Seriously, WTFF? Is it just a show-off option to make us think it’s
> better to use a Recommends instead?

I proposed this option[1] as an attempt to mitigate the breakage
caused by having NM installed when wicd is being used to configure
networking. I personally don't like it, but I proposed it to attempt
to address your concerns about making sure that NM was installed,
while still mitigating breakage for people who have installed wicd.

> > B 5. Bugs in network-manager-gnome which break the functionality of
> > Bexisting /etc/network/interfaces rules are to be considered RC.
> 
> Not replacing /e/n/i means that NM will not detect your connection,
> and as such your desktop will be unusable.

In what specific way?[2]

Don Armstrong

1: http://lists.debian.org/debian-ctte/2012/10/msg00027.html with
rationale here:
http://lists.debian.org/debian-ctte/2012/10/msg00036.html along with
the ensuing thread.

2: I still don't have an answer to this question after I and others
have repeatedly asked for it.
http://lists.debian.org/debian-ctte/2012/10/msg00011.html
-- 
life's not a paragraph
And death i think is no parenthesis
 -- e.e. cummings "Four VII" _is 5_

http://www.donarmstrong.com  http://rzlab.ucr.edu

--
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/20121024171354.gt11...@rzlab.ucr.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-24 Thread Bdale Garbee

Josselin Mouette  writes:

> Our very intent is that squeeze users who have gnome installed but not
> NM *do* find that NM becomes installed when they upgrade to wheezy.

Thank you for stating this so plainly.

>> 9. It is disappointing that this proposed solution to the problem was
>>not mentioned during the TC discussion.  If it had been, it could
>>have been accepted or rejected by the TC at the time.
>
> Maybe more communication would have occurred if this discussion had been
> driven by a reasonable person.
  ...
> I still stand on the stance that Ian’s behavior is unacceptable; and
> proposing this kind of passive-agressive wording in a TC decision is
> part of the problem. 

While I understand your feelings on this and agree that Ian has allowed
his emotions to get the better of him at least once in this process, as
I've already asserted, one of the reason we have a *committee* defined
by our constitution to act as the ultimate decision making authority on
technical issues is precisely to ensure that the emotions of a single
individual do not dictate project policy.

Please un-wind your emotional reaction to Ian's participation in this
process, and realize that his is only one voice, and you are dealing
with a level-headed committee that is trying very hard to make the best
decisions possible for the project overall.  There is no "crusade" here
beyond the genuine desire to deliver on item 4 of our Social Contract,
and the longer you, Michael, and others continue to assert that there
is, the harder it is for those of us less *emotionally* invested in this
decision to stay focused on doing the right things for Debian.

> He should step down from the committee or be forced
> to do so.

Personally, I think Ian's usual objectivity and attention to detail are
valuable to the committee... enough so that I'm willing to cope with 
an occasional reminder that he is only human, and I would not initiate a
move to remove him from the committee per 6.2.5 of our Constitution.

However, if you feel sufficiently strongly about this, 4.1.4 of our
Constitution suggests that a GR resulting in a super-majority of support
From voting members of the project should suffice to remove a TC member.

> In the current situation, I do not feel bound by any decisions the
> committee might make.

A standard part of becoming a DD through the NM process is accepting the
Social Contract and agreeing to be bound by our Constitution.  And it is
our Constitution that defines the existence and role of the Technical
Committee.

I urge to you reconsider and retract this statement. 

Regards,

Bdale

pgpnQNmK0pxp0.pgp
Description: PGP signature

Bug#688772: gnome Depends network-manager-gnome

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> Discussion seems to have stopped on this bug; I have drafted an
> additional set of options for discussion, both of which borrow
> liberally from ian's draft, and are presented below.

Thanks.

> I'd like to either reconcile these options in the next few days so we
> can vote on this issue and resolve it before it impacts the release
> schedule. [I don't anticipate calling for votes before our meeting on
> Thursday, but we should at least try to get any preliminaries out of
> the way first if possible.]

I would be happy with your option A.

Ian.


-- 
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/20615.53167.867261.483...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

Josselin Mouette writes ("Bug#688772: gnome Depends network-manager-gnome"):
> Le mardi 23 octobre 2012 à 15:16 -0700, Don Armstrong a écrit :
> > 2. Our intent, as stated in the rationale section of our previous
> >decision (#681834, paras 3 and 5), is that squeeze users who have
> >gnome installed but not network-manager do not find that
> >network-manager becomes installed when they upgrade to wheezy.
> 
> There lies the real disagreement.
> 
> Our very intent is that squeeze users who have gnome installed but not
> NM *do* find that NM becomes installed when they upgrade to wheezy.

Thank you for stating this so clearly.  

I'm not sure there's much more to be said about this.  I would like to
remind my colleagues on the TC that these users are users who have
deliberately chosen to disregard the recommendation of n-m.  (And yes,
I do mean also users who have globally disabled recommends.)

So as I have said we face a clear choice between respecting the
explicit decisions of our users, and the strongly expressed views of
the maintainer.  There can be only one answer to this, surely ?

> Everything else Ian and you have proposed derives from the fact that you
> want to force NM out.

What I want is for users who have forced NM out to have that decision
respected.  I am entirely happy for NM to remain the default.

> > B 4. We overrule the decision of the meta-gnome maintainers to add a
> > Bdependency from gnome to network-manager-gnome; this dependency
> > Bshould be replaced with a dependecy on network-manager-gnome (>=
> > B0.9.4) | wicd.
> 
> Seriously, WTFF? Is it just a show-off option to make us think it’s
> better to use a Recommends instead?

As I have said I think this option is a bad idea.  But it has arisen
as a result of attempts by my colleagues on the TC to find a
compromise position between your view, and mine.  In the absence of
clear and technically-grounded statements from the GNOME maintainers
this has been happening in a vacuum, with my colleagues apparently
guessing what your objectives are.

> And as for Ian’s hateful prose…
> 
> > 8. We specifically forbid anyone from introducing in wheezy, or
> >in sid until wheezy is released:
> > a. Any new or enhanced dependencies, or any other mechanisms,
> >which increase the likelihood of network-manager being
> >installed;
> > b. Any new or enhanced user-facing warnings, imprecations, or
> >other kinds of message regarding the alleged desirability or
> >requirement to install network-manager;
> > c. Any change which in any way impairs (or further impairs) the
> >functioning of systems with GNOME components installed but
> >without network-manager;
> > d. Any change which is contrary to the spirit or intent of either
> >our previous resolution in #681834 or this resolution.
> >without first obtaining the permission of at least one member of
> >the Technical Committee.
> 
> Does it really need commenting?

I'm glad to hear that you don't intend to do any of these things.
Thank you.  Then there is no need for us to say so explicitly that you
shouldn't.

Ian.


--
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/20615.53063.186581.106...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

Michael Biebl writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On 24.10.2012 03:29, Sam Hartman wrote:
> > Don, in your option 4B, I wonder if it would be a good idea to  have the
> > depend be something like g-n-m|wicd|no-network-manager
> 
> The "gnome" meta-package certainly won't get an alternative dependency
> on wicd. That would be completely stupid and miss the point of this
> dependency. The GNOME desktop has zero integration with wicd, so this
> alternative dependency is completely backwards.
> Why don't you force a dependency on ifupdown on us, or ifplugd or whatever.

Shockingly, I find myself in agreement with at least some of the views
of the GNOME maintainers.  As I have said, I don't think this proposed
dependency on wicd makes any kind of sense.  It achieves neither the
objectives of the GNOME maintainers nor the objectives of users who
have chosen to remove n-m.

AIUI the point of introducing wicd was to try to find some kind of
compromise.  Given the response from the GNOME maintainers, I think it
is a bad idea.

Of course, Don, you're still entitled to put it on the ballot.  And to
be honest if it's there I would still vote for it over FD as it does
assist some of the affected users.  But really I think it's just
introducing confusion (or, indeed, is itself the result of confusion)
and it should be dropped.

Ian.

-- 
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/20615.52590.255737.869...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-24 Thread Josselin Mouette

Let me comment on the proposals again.

Le mardi 23 octobre 2012 à 15:16 -0700, Don Armstrong a écrit :
> 2. Our intent, as stated in the rationale section of our previous
>decision (#681834, paras 3 and 5), is that squeeze users who have
>gnome installed but not network-manager do not find that
>network-manager becomes installed when they upgrade to wheezy.

There lies the real disagreement.

Our very intent is that squeeze users who have gnome installed but not
NM *do* find that NM becomes installed when they upgrade to wheezy.
(Actually we should have done that for the lenny→squeeze upgrade but
vocal people already won that time.)

The fact that it could potentially, in very specific to-be-described
cases, break something, should be documented in the release notes.

Everything else Ian and you have proposed derives from the fact that you
want to force NM out.

> B 4. We overrule the decision of the meta-gnome maintainers to add a
> Bdependency from gnome to network-manager-gnome; this dependency
> Bshould be replaced with a dependecy on network-manager-gnome (>=
> B0.9.4) | wicd.

Seriously, WTFF? Is it just a show-off option to make us think it’s
better to use a Recommends instead?

> B 5. Bugs in network-manager-gnome which break the functionality of
> Bexisting /etc/network/interfaces rules are to be considered RC.

Not replacing /e/n/i means that NM will not detect your connection, and
as such your desktop will be unusable. If your intent is to generate RC
bugs, congratulations, but that will not help with the release.

And as for Ian’s hateful prose…

> 8. We specifically forbid anyone from introducing in wheezy, or
>in sid until wheezy is released:
> a. Any new or enhanced dependencies, or any other mechanisms,
>which increase the likelihood of network-manager being
>installed;
> b. Any new or enhanced user-facing warnings, imprecations, or
>other kinds of message regarding the alleged desirability or
>requirement to install network-manager;
> c. Any change which in any way impairs (or further impairs) the
>functioning of systems with GNOME components installed but
>without network-manager;
> d. Any change which is contrary to the spirit or intent of either
>our previous resolution in #681834 or this resolution.
>without first obtaining the permission of at least one member of
>the Technical Committee.

Does it really need commenting?

> 9. It is disappointing that this proposed solution to the problem was
>not mentioned during the TC discussion.  If it had been, it could
>have been accepted or rejected by the TC at the time.

Maybe more communication would have occurred if this discussion had been
driven by a reasonable person.

> 10. We remind everyone that the Constitution requires members of the
>project not to work against decisions properly made according to
>the project's governance processes.  On this occasion we do not
>feel it necessary to refer anyone to the Debian Account Managers
>asking for a review of their status.

I still stand on the stance that Ian’s behavior is unacceptable; and
proposing this kind of passive-agressive wording in a TC decision is
part of the problem. He should step down from the committee or be forced
to do so.

In the current situation, I do not feel bound by any decisions the
committee might make.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1351068709.3536.275.camel@pi0307572

Bug#688772: gnome Depends network-manager-gnome

2012-10-24 Thread Josselin Mouette

Le mercredi 24 octobre 2012 à 09:57 +0200, Andreas Barth a écrit : 
> > This whole crusade by the ctte is so ridiculous, but unfortunately I
> > can't laugh about that anymore.
> 
> Where is there a crusade? I don't see any. 

Maybe you should remove that blindfold of yours?

> And btw, it doesn't help to replace reason by emotion.

Reason has abandoned this discussion long ago. This has always been
about people who don’t even use GNOME but who won’t accept the idea that
we would install NM on other people’s computers.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1351067906.3536.261.camel@pi0307572

Bug#688772: gnome Depends network-manager-gnome

2012-10-24 Thread Andreas Barth

* Michael Biebl (bi...@debian.org) [121024 03:57]:
> On 24.10.2012 03:29, Sam Hartman wrote:
> > Don, in your option 4B, I wonder if it would be a good idea to  have the
> > depend be something like g-n-m|wicd|no-network-manager
> 
> The "gnome" meta-package certainly won't get an alternative dependency
> on wicd. That would be completely stupid and miss the point of this
> dependency. The GNOME desktop has zero integration with wicd, so this
> alternative dependency is completely backwards.

You think it would be better to move it to recommends instead?


> Why don't you force a dependency on ifupdown on us, or ifplugd or whatever.

Do you think that would be better for our users?


> This whole crusade by the ctte is so ridiculous, but unfortunately I
> can't laugh about that anymore.

Where is there a crusade? I don't see any. And btw, it doesn't help to
replace reason by emotion.



Andi


-- 
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/20121024075707.gj26...@mails.so.argh.org

Bug#688772: gnome Depends network-manager-gnome

2012-10-23 Thread Michael Biebl

On 24.10.2012 03:29, Sam Hartman wrote:
> Don, in your option 4B, I wonder if it would be a good idea to  have the
> depend be something like g-n-m|wicd|no-network-manager

The "gnome" meta-package certainly won't get an alternative dependency
on wicd. That would be completely stupid and miss the point of this
dependency. The GNOME desktop has zero integration with wicd, so this
alternative dependency is completely backwards.
Why don't you force a dependency on ifupdown on us, or ifplugd or whatever.

This whole crusade by the ctte is so ridiculous, but unfortunately I
can't laugh about that anymore.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

signature.asc
Description: OpenPGP digital signature

Bug#688772: gnome Depends network-manager-gnome

2012-10-23 Thread Sam Hartman

Don, in your option 4B, I wonder if it would be a good idea to  have the
depend be something like g-n-m|wicd|no-network-manager

ANd have an empty extra package that users can install if they really
want neither n-m or wicd?

While I don't get a vote, I think that would be a reasonable option if
you buy the idea that you want to install n-m for people who uninstalled
it for squeeze, but you still want a way for people to say "no I hate
n-m".

I think 4A is a better option, bum my proposal may help the question of
whether the TC missed another case where n-m is the wrong answer.


-- 
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/tslzk3ck67s@mit.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-23 Thread Don Armstrong

On Tue, 25 Sep 2012, Ian Jackson wrote:
> This bug is to track this issue. Please send all discussion on this
> topic only to this bug report. I will make sure that the gnome
> maintainers are pointed to this bug report.

Discussion seems to have stopped on this bug; I have drafted an
additional set of options for discussion, both of which borrow
liberally from ian's draft, and are presented below.

I'd like to either reconcile these options in the next few days so we
can vote on this issue and resolve it before it impacts the release
schedule. [I don't anticipate calling for votes before our meeting on
Thursday, but we should at least try to get any preliminaries out of
the way first if possible.]

Don Armstrong

-- 
When I was a kid I used to pray every night for a new bicycle. Then I 
realized that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
 -- Emo Philips.

http://www.donarmstrong.com  http://rzlab.ucr.edu
1. The TC notes the decision of the meta-gnome maintainers to
   implement the TC decision in #681834 by:
(a) softening the dependency in the gnome-core metapackage
from Depends to Recommends, as required
(b) adding a new dependency in the gnome metapackage,
as a Depends.  (In squeeze, this is where the dependency
was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheezy.

3. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

A 4. We overrule the decision of the meta-gnome maintainers to add a
Adependency from gnome to network-manager-gnome; this dependency
Ashould be removed for the release of wheezy.
A 
A 5. We request that the Release Team unblock update(s) to meta-gnome so
Athat our decisions may be implemented in wheezy.

B 4. We overrule the decision of the meta-gnome maintainers to add a
Bdependency from gnome to network-manager-gnome; this dependency
Bshould be replaced with a dependecy on network-manager-gnome (>=
B0.9.4) | wicd.
B
B 5. Bugs in network-manager-gnome which break the functionality of
Bexisting /etc/network/interfaces rules are to be considered RC.
B
B 6. We request that the Release Team unblock update(s) to meta-gnome so
Bthat our decisions may be implemented in wheezy.
Whereas

1. The TC notes the decision of the meta-gnome maintainers to
   implement our decision in #681834 by:
(a) softening the dependency in the gnome-core metapackage
from Depends to Recommends, as required
(b) adding a new dependency in the gnome metapackage,
as a Depends.  (In squeeze, this is where the dependency
was, but it was a Recommends.)

2. Our intent, as stated in the rationale section of our previous
   decision (#681834, paras 3 and 5), is that squeeze users who have
   gnome installed but not network-manager do not find that
   network-manager becomes installed when they upgrade to wheezy.

3. The actions of the meta-gnome maintainers do not achieve this
   objective.

4. Insofar as any reasons have been advanced for the meta-gnome
   maintainer's decision, we do not find them convincing.

5. A Recommends from gnome to network-manager-gnome would serve no
   purpose in wheezy as gnome Depends on gnome-core which already
   Recommends network-manager-gnome.

Therefore

6. We overrule the decision of the meta-gnome maintainers to add a
   dependency from gnome to network-manager-gnome.  This dependency
   should be removed.

7. We request that the Release Team unblock update(s) to meta-gnome so
   that our decisions may be implemented in wheezy.

8. We specifically forbid anyone from introducing in wheezy, or
   in sid until wheezy is released:
a. Any new or enhanced dependencies, or any other mechanisms,
   which increase the likelihood of network-manager being
   installed;
b. Any new or enhanced user-facing warnings, imprecations, or
   other kinds of message regarding the alleged desirability or
   requirement to install network-manager;
c. Any change which in any way impairs (or further impairs) the
   functioning of systems with GNOME components installed but
   without network-manager;
d. Any change which is contrary to the spirit or intent of either
   our previous resolution in #681834 or this resolution.
   without first obtaining the permission of at least one member of
   the Technical Committee.

Furthermore

9. It is disappointing that this proposed solution to the problem was
   not mentioned during the TC discussion.  If it had been, it could
   have been accepted or rejected by the TC at the time.

10. We remind everyone that the Constitution

Re: Bug#688772: gnome Depends network-manager-gnome

2012-10-15 Thread Roger Leigh

On Mon, Oct 15, 2012 at 04:40:10AM -0400, Chris Knadle wrote:
> On Sunday, October 14, 2012 16:27:29, Tollef Fog Heen wrote:
> > ]] Ian Jackson
> > 
> > > This is particularly true when these users have already decided not to
> > > take the maintainer's advice.  By the decision not to install n-m,
> > > those users have already overruled the maintainer for their own
> > > systems.  To say that we think the maintainer knows best is going
> > > against the clearly expressed opinion of a user who has deliberately
> > > deinstalled n-m.
> > 
> > .. or who just has an old system which didn't have Recommends
> > installation enabled by default, or where it's been disabled since
> > Recommends end up dragging in all kinds of stuff.
> 
> This again is a user choice, which the upgrade to Depends would override.
> 
> More importantly, this is /not/ a user choice that someone /new/ to Debian 
> would make; it takes experience to find out that this option exists, 
> and in setting the option the /user/ takes responsibility for the resulting 
> behavior, because the setting /overrides/ the default behavior.

While I can't find the references immediately to hand, I distinctly
remember looking at various GNOME developer blogs and list posts
where they were stating that network-manager was not considered a
one-size-fits-all solution, and that it would remain optional
because of that.  That was just a few months ago.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20121015091410.gn18...@codelibre.net

Re: Bug#688772: gnome Depends network-manager-gnome

2012-10-15 Thread Chris Knadle

On Sunday, October 14, 2012 16:27:29, Tollef Fog Heen wrote:
> ]] Ian Jackson
> 
> > This is particularly true when these users have already decided not to
> > take the maintainer's advice.  By the decision not to install n-m,
> > those users have already overruled the maintainer for their own
> > systems.  To say that we think the maintainer knows best is going
> > against the clearly expressed opinion of a user who has deliberately
> > deinstalled n-m.
> 
> .. or who just has an old system which didn't have Recommends
> installation enabled by default, or where it's been disabled since
> Recommends end up dragging in all kinds of stuff.

This again is a user choice, which the upgrade to Depends would override.

More importantly, this is /not/ a user choice that someone /new/ to Debian 
would make; it takes experience to find out that this option exists, 
and in setting the option the /user/ takes responsibility for the resulting 
behavior, because the setting /overrides/ the default behavior.

> It's a bit late now, but when we changed the default for Recommends to
> be on by default, we should have purged the archive of existing
> Recommends.

... you mean by removing /all/ user choices?  Why are user options being 
/feared/ here?

> > And, as you say, reinstalling n-m during the upgrade is deeply
> > problematic.  At the very best it will have no beneficial
> > effect until the user take explicit action to reconfigure their
> > networking to use n-m.  There is of course no particular reason why it
> > would be difficult for a user who changed their mind to reinstall n-m
> > as and when they felt like it - under conditions where they are
> > prepared for a failure of their networking and have the time and
> > inclination to reconfigure.
> 
> At best, it will mean the user who previously had a working networking
> menu still has one after the upgrade.  wicd, from what's been told here,
> does not integrate at all with gnome-shell, meaning those users are now
> left without an obvious way to configure their networking.
> 
> I don't think that's in the users's best interest either.

The fact that wicd-gtk doesn't integrate into the Gnome3 shell is unfortunate, 
however that fact is now being used to excuse *breaking* users of wicd, and 
simultaneously leaving them *clueless* as to the cause, with only an error of 
"bad password" to work with.  n-m does not have "Breaks: wicd-daemon" in the 
control field of the package, there is no mention of breaking wicd in any of 
the n-m documentation, nor how to disable n-m via and update-rc.d command.

I find your mention of "user's best interest" illogical here, because right up 
to this point of the email the argument is all about *overriding* user choice, 
and regretting not doing so even more.  How can /overriding/ the user be in 
the user's best interest?

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

-- 
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/201210150440.10782.chris.kna...@coredump.us

Re: Bug#688772: gnome Depends network-manager-gnome

2012-10-14 Thread Tollef Fog Heen

]] Ian Jackson 

> This is particularly true when these users have already decided not to
> take the maintainer's advice.  By the decision not to install n-m,
> those users have already overruled the maintainer for their own
> systems.  To say that we think the maintainer knows best is going
> against the clearly expressed opinion of a user who has deliberately
> deinstalled n-m.

.. or who just has an old system which didn't have Recommends
installation enabled by default, or where it's been disabled since
Recommends end up dragging in all kinds of stuff.

It's a bit late now, but when we changed the default for Recommends to
be on by default, we should have purged the archive of existing
Recommends.

> And, as you say, reinstalling n-m during the upgrade is deeply
> problematic.  At the very best it will have no beneficial
> effect until the user take explicit action to reconfigure their
> networking to use n-m.  There is of course no particular reason why it
> would be difficult for a user who changed their mind to reinstall n-m
> as and when they felt like it - under conditions where they are
> prepared for a failure of their networking and have the time and
> inclination to reconfigure.

At best, it will mean the user who previously had a working networking
menu still has one after the upgrade.  wicd, from what's been told here,
does not integrate at all with gnome-shell, meaning those users are now
left without an obvious way to configure their networking.

I don't think that's in the users's best interest either.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87mwzou7da@xoog.err.no

Bug#688772: gnome Depends network-manager-gnome

2012-10-14 Thread Ian Jackson

Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
> That's the reason why I'm inclined to try to stay out of the decision as
> much as possible and leave it to the GNOME maintainers, who know
> considerably more about the system than I do.

One might as well say that we should leave it to the users, who know
considerably more about their system.

It is important to remember that fundamentally the dispute here is not
between me and the gnome maintainers.  I don't have a dog in the fight
- or at least I didn't until I called out the maintainers' mistakes.
(I don't have gnome or gnome-core on any of my systems and I do have
network-manager on my netbook.)

The complainants are certain users who have decided against n-m.  The
question is whether the disbenefit to those users outweighs the
alleged benefit to other users who previously decided against n-m but
who in the opinion of the gnome maintainers would be best served by
reinstalling n-m.

It would take an extremely convincing argument for me to conclude that
we should overrule an explicit decision by a user in favour of a
blanket decision by a maintainer.

This is particularly true when these users have already decided not to
take the maintainer's advice.  By the decision not to install n-m,
those users have already overruled the maintainer for their own
systems.  To say that we think the maintainer knows best is going
against the clearly expressed opinion of a user who has deliberately
deinstalled n-m.

And, as you say, reinstalling n-m during the upgrade is deeply
problematic.  At the very best it will have no beneficial
effect until the user take explicit action to reconfigure their
networking to use n-m.  There is of course no particular reason why it
would be difficult for a user who changed their mind to reinstall n-m
as and when they felt like it - under conditions where they are
prepared for a failure of their networking and have the time and
inclination to reconfigure.

Under these circumstances I think it would be wrong of us to
countenance the maintainer's escalation in the war of competing
preferences.

> That's the reason why I'm inclined to try to stay out of the decision as
> much as possible and leave it to the GNOME maintainers, who know
> considerably more about the system than I do.  While the current situation
> is not the compromise that I would have proposed, it does feel like a
> workable compromise (in conjunction with release notes), and I do think
> it's valuable to compromise some in situations like this.

I think this proposed compromise is a compromise between the rights of
our users to configure their systems the way they want, and the
desire of the GNOME project and its supporters to make a strong
declaration about the status of Network Manager.

The claims that n-m has improved have to be seen in the context of a
persistent and long-running battle between that strong declaration and
users' desire to set up their systems the way they prefer.  The reason
there is so much heat here is precisely because of that long-running
battle.  But, frankly, in that battle I think there is a right side
and a wrong side.

I don't think we should compromise on the principle that the software
we ship should honour the explicitly stated wishes of our users.

> The tension in the discussion is making it very hard to hold that
> position.  People on all sides of this discussion seem to be pushing it
> towards becoming a referendum on the legitimacy of the Technical Committee
> rather than a method for arriving at the best all-around compromise for
> both GNOME users and the project, and that's making me really
> uncomfortable.

A referendum on the legitimacy of the TC would surely be a GR.

I'm just trying to do the right thing by the users.  That means that
when the user chooses to disregard the maintainers' advice, we should
not allow the maintainer to now impose that advice simply because the
maintainer claims that the basis for the user's original decision is
no longer true.  That is a decision for the user, not the maintainer,
to make.

Ian.


-- 
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/20603.6779.555104.185...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-14 Thread Russ Allbery

Ian Jackson  writes:
> Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):

>> Whether or not one agrees with that reason, I do think it's cogent and
>> goes directly to the point, namely upgrade behavior.

> Do you think it's a good reason, in the case of n-m ?

I'm hesitant to express a strong opinion.  I can see good arguments for
both sides.  The way in which integration of components in GNOME is done
has changed considerably in GNOME 3 as I understand it, and wicd does not
integrate well with the new way of doing integration.  The behavior of n-m
with statically-configured local networks has also improved considerably,
according to various discussion in this thread.

Having n-m take over from wicd during an upgrade is still awkward.
However, it's not at all clear that the reasons why I, at least, switched
to wicd when I was using GNOME would still apply, so it's possible that
many users will now be better off with n-m again.

All that weighs against what I think is a fairly compelling case for using
Recommends in metapackages.

I'm feeling particularly sensitive to the fact that I personally don't use
the software involved, in part because I prefer a different philosophical
approach to assembling my desktop, and therefore the reasons why I might
make decisions about components are not necessarily in the spirit of
GNOME.

That's the reason why I'm inclined to try to stay out of the decision as
much as possible and leave it to the GNOME maintainers, who know
considerably more about the system than I do.  While the current situation
is not the compromise that I would have proposed, it does feel like a
workable compromise (in conjunction with release notes), and I do think
it's valuable to compromise some in situations like this.

The tension in the discussion is making it very hard to hold that
position.  People on all sides of this discussion seem to be pushing it
towards becoming a referendum on the legitimacy of the Technical Committee
rather than a method for arriving at the best all-around compromise for
both GNOME users and the project, and that's making me really
uncomfortable.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>

-- 
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/87626cluwf@windlord.stanford.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-14 Thread Ian Jackson

Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
> Actually, Josselin did say, in one of his recent messages, the reason that
> I had hypothesized: that n-m is so much better that he's not sure that
> people who previously opted out of n-m stated a preference that should
> apply to the current n-m.

I did read that, and basically what it amounts to is this:

 N-M has improved enough that for a user who has deliberately decided
 to remove it, we should no longer respect that choice (as being no
 longer applicable to the current situation).

Now I acknowledge that there might be cases where such a statement
about a user's prior choice might be true.  I think such situations
will be very rare but it is possible that they might exist.

However, we are not making this decision in the abstract.  We are
making it for n-m, specifically.  And in the cases where a user has
deliberately removed n-m they will have made other arrangements for
their networking.  Under those circumstances reinstalling n-m during
the upgrade is certainly not helpful to the user; at best it does
nothing useful because n-m does not disturb their existing setup.  At
worst it breaks something and forces the user to untangle the mess.

> Whether or not one agrees with that reason, I do think it's cogent and
> goes directly to the point, namely upgrade behavior.

Do you think it's a good reason, in the case of n-m ?

Ian.


-- 
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/20602.64331.731583.172...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-13 Thread Bdale Garbee

Josselin Mouette  writes:

> Le vendredi 12 octobre 2012 à 21:07 +0200, Stefano Zacchiroli a écrit :
>> For lack of a better synopsis, the argument there is "because recommends
>> do not behave properly across upgrades".
>
> And also, the purpose of metapackages is to ship dependencies.

Repeating this more times doesn't make it more true.  The purpose of
metapackages is to deliver meta-data, including dependency
information.  That information does not have to be, and in many cases
should *not* be, in the form of hard dependencies.

Bdale

pgpUsY2ORXh8Y.pgp
Description: PGP signature

Bug#688772: gnome Depends network-manager-gnome

2012-10-13 Thread Chris Knadle

On Friday, October 12, 2012 14:38:07, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > On Fri, 12 Oct 2012, Ian Jackson wrote:
> > > Why do you think the gnome metapackage depending on, rather than
> > > recommending, wicd, is a good idea?
> > 
> > The primary case of NM breaking things is when it's installed with
> > wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.
> 
> There are no other competitors to wicd and n-m then ?

'apt-cache search "network manager"' also comes up with nova-network which is 
a network manager for OpenStack, which I think is Cloud related, but I'm not 
familiar with it.  Here's the relevant portion of the description:

   This package equips a system to function as a network node. This
   service is responsible for managing floating and fixed IP addresses,
   DHCP, bridging, and VLANs, and in some cases acts as a gateway.
   Different networking strategies can be accessed by setting the
   network_manager flag to FlatManager, FlatDHCPManager, or VlanManager
   (the default).

> > > For example, consider the position of someone who has deliberately
> > > removed n-m in squeeze, and is using ifupdown or running ifconfig by
> > > hand or whatever, and upgrades to wheezy. This still gives them n-m
> > > back. That's not respecting their previous choice to remove it.
> > 
> > Right, but if they get NM back, and nothing breaks because of it,[0]
> > it's just the same as any other package being installed by a meta
> > package. They've wasted some disk space, and they've got another
> > program running, but everything continues to work.
> 
> And you're saying nothing will break because in the case where they
> have wicd, n-m won't be installed because of the alternative.  And in
> the case where they don't have wicd "there are no such bugs that
> aren't rc".
> 
> Are we sure that all these rc bugs are going to be fixed and not
> downgraded at the last moment ?  Are we sure that we will find them
> all, for that matter, before the release ?
> 
> Given the very strong insistence by n-m's proponents that these bugs
> aren't even real, in many cases, it seems more likely that n-m will be
> released in wheezy with infelicities which will be argued by the gnome
> maintainers to be not bugs, or not rc, or someone else's fault.
> 
> For example, if I want to use ifupdown then I probably don't want n-m
> to bring up even interfaces which exist but which I haven't mentioned
> in /etc/network/interfaces - but managing those interfaces is
> precisely the point of n-m.  So I'm cast back into "install n-m but
> disable it", which is clearly inferior.
> 
> The result is surely going to be more friction between users who find
> n-m doesn't work for them, and developers who insist on forcing n-m on
> them.

I keep thinking about this in the context of laptops, and forgetting the 
context of "traditional desktop boxes" and servers.  In the context of either, 
it's common to want to install Gnome without any wireless manager installed 
and use ifupdown "just like with any other server" -- and specifically not 
install n-m due to previous bad experiences people have had with it, or to 
have trouble figuring out how to configure n-m for a static IP if they aren't 
able to remove it.  [It can do it, but is apparently not intuitive.]

There are a couple of people at my local LUG that run Gnome on their server 
(usually on Ubuntu).  I've overheard a few discussions about the difficulties 
of removing n-m in this context, and the advice given to the server owner 
generally ranges between "remove n-m -- it's worth it" to "you might as well 
configure n-m for a static IP, because the system will fight you on removing 
it too much".

I thought running Gnome3 on a server was a crazy idea until I asked about it; 
the basic premise is that the server then has a similar interface as the 
traditional Desktop, and allows for running GUI administration programs.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

-- 
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/201210130544.53419.chris.kna...@coredump.us

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Russ Allbery

Ian Jackson  writes:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):

>> The primary case of NM breaking things is when it's installed with
>> wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.

> There are no other competitors to wicd and n-m then ?

It's also possible to configure wireless networking manually without using
either wicd or ifup and using wpa_supplicant directly, but I think that's
close enough to the ifup use case (and similar enough from the n-m
perspective) that we can consider it the same.

There may be other more comprehensive systems like n-m and wicd, but if so
I've not heard of them.

> They do indeed appear to strongly believe that but they have advanced no
> cogent reasons.  (You agree, don't you, that they haven't advanced any
> cogent reasons?)

Actually, Josselin did say, in one of his recent messages, the reason that
I had hypothesized: that n-m is so much better that he's not sure that
people who previously opted out of n-m stated a preference that should
apply to the current n-m.

Whether or not one agrees with that reason, I do think it's cogent and
goes directly to the point, namely upgrade behavior.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>

-- 
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/87ipafp8we@windlord.stanford.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Josselin Mouette

Le vendredi 12 octobre 2012 à 13:06 -0700, Don Armstrong a écrit :
> Continuing to attack Ian like this is not helpful. Please stop.

No, you please stop.

You should be glad there is one remaining GNOME maintainer willing to
talk about the crusade. Seeing Ian talk his usual crap is a good way to
reduce this number further.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1350073704.8217.12.camel@tomoe

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Josselin Mouette

Le vendredi 12 octobre 2012 à 21:07 +0200, Stefano Zacchiroli a écrit :
> For lack of a better synopsis, the argument there is "because recommends
> do not behave properly across upgrades".

And also, the purpose of metapackages is to ship dependencies.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1350073354.8217.7.camel@tomoe

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Don Armstrong

On Fri, 12 Oct 2012, Josselin Mouette wrote:
> Le vendredi 12 octobre 2012 à 19:51 +0100, Ian Jackson a écrit :
> > > The simpler hypothesis is that there is no reason.
> > 
> > I should expand on that, because it makes it sound like I think the
> > gnome maintainerss' behaviour is entirely inexplicable.  
> 
> Don’t worry, it just sounds like yourself.

Continuing to attack Ian like this is not helpful. Please stop.


Don Armstrong

-- 
UF: What's your favorite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
counter does not click, the coffee, she is just not thick."

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20121012200629.go7...@teltox.donarmstrong.com

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Josselin Mouette

Le vendredi 12 octobre 2012 à 19:51 +0100, Ian Jackson a écrit :
> > The simpler hypothesis is that there is no reason.
> 
> I should expand on that, because it makes it sound like I think the
> gnome maintainerss' behaviour is entirely inexplicable.  

Don’t worry, it just sounds like yourself.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1350071715.8217.4.camel@tomoe

Bug#688772: gnome Depends network-manager-gnome

Stefano Zacchiroli writes ("Bug#688772: gnome Depends network-manager-gnome"):
> To be fair, it seems to me that Joss has provided an additional answer
> to the "why recommends?" question in
> 
>   https://lists.debian.org/debian-ctte/2012/09/msg00089.html
> 
> For lack of a better synopsis, the argument there is "because recommends
> do not behave properly across upgrades".

That's a reason not to use Recommends in metapackages everywhere
(indeed, it's _the_ reason why metapackages shouldn't just all use
Recommends).

But in this specific case, it isn't a good reason, because the bug
(failing to honour a newly-appearing Recommends) will not occur in the
case of people upgrading from squeeze's "gnome", because the squeeze's
"gnome" package already had that recommends.

Ian.


-- 
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/20600.27758.415028.479...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Stefano Zacchiroli

On Fri, Oct 12, 2012 at 07:51:44PM +0100, Ian Jackson wrote:
> It seems to me that the gnome maintainers have a philosophical view
> that Network Manager is very strongly part of GNOME, and that they
> feel that this philosophical position can only be properly reflected
> by a hard dependency.  That is, that demoting the dependency to
> Recommends would be failing to properly give effect to the truth that
> N-M is part of GNOME.

To be fair, it seems to me that Joss has provided an additional answer
to the "why recommends?" question in

  https://lists.debian.org/debian-ctte/2012/09/msg00089.html

For lack of a better synopsis, the argument there is "because recommends
do not behave properly across upgrades".

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#688772: gnome Depends network-manager-gnome

Ian Jackson writes ("Re: Bug#688772: gnome Depends network-manager-gnome"):
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > That's what I'm confused about too, but I'm assuming that there is
> > indeed a reason why Recommends isn't enough, and the gnome meta
> > package has to Depends: NM. [The questions I posed earlier still
> > haven't been answered, unfortunately.]
...
> The simpler hypothesis is that there is no reason.

I should expand on that, because it makes it sound like I think the
gnome maintainerss' behaviour is entirely inexplicable.  That's not
what I mean.  I should have said "no good reason".

It seems to me that the gnome maintainers have a philosophical view
that Network Manager is very strongly part of GNOME, and that they
feel that this philosophical position can only be properly reflected
by a hard dependency.  That is, that demoting the dependency to
Recommends would be failing to properly give effect to the truth that
N-M is part of GNOME.

This seems to me to be the core of the opposition.  Naturally
I disagree that that's a good reason for having a Depends.

Ian.


-- 
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/20600.26304.54903.586...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 12 Oct 2012, Sam Hartman wrote:
> > I understand that the Gnome maintainers want N-M installed by default.
> > Except I think recommends gets you that.
> 
> That's what I'm confused about too, but I'm assuming that there is
> indeed a reason why Recommends isn't enough, and the gnome meta
> package has to Depends: NM. [The questions I posed earlier still
> haven't been answered, unfortunately.]

I think your assumption is incorrect.

The gnome maintainers have written a great deal in these bug reports
but have failed to come up with the reason you are looking for.

The simpler hypothesis is that there is no reason.

Ian.


-- 
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/20600.25988.303821.800...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Don Armstrong

On Fri, 12 Oct 2012, Sam Hartman wrote:
> I'm still confused why recommends doesn't work for everyone.
>
> I understand that the Gnome maintainers want N-M installed by default.
> Except I think recommends gets you that.

That's what I'm confused about too, but I'm assuming that there is
indeed a reason why Recommends isn't enough, and the gnome meta
package has to Depends: NM. [The questions I posed earlier still
haven't been answered, unfortunately.]


Don Armstrong

-- 
"For those who understand, no explanation is necessary.
 For those who do not, none is possible."

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121012184137.gh7...@teltox.donarmstrong.com

Bug#688772: gnome Depends network-manager-gnome

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 12 Oct 2012, Ian Jackson wrote:
> > Why do you think the gnome metapackage depending on, rather than
> > recommending, wicd, is a good idea?
> 
> The primary case of NM breaking things is when it's installed with
> wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.

There are no other competitors to wicd and n-m then ?

> > For example, consider the position of someone who has deliberately
> > removed n-m in squeeze, and is using ifupdown or running ifconfig by
> > hand or whatever, and upgrades to wheezy. This still gives them n-m
> > back. That's not respecting their previous choice to remove it.
> 
> Right, but if they get NM back, and nothing breaks because of it,[0]
> it's just the same as any other package being installed by a meta
> package. They've wasted some disk space, and they've got another
> program running, but everything continues to work.

And you're saying nothing will break because in the case where they
have wicd, n-m won't be installed because of the alternative.  And in
the case where they don't have wicd "there are no such bugs that
aren't rc".

Are we sure that all these rc bugs are going to be fixed and not
downgraded at the last moment ?  Are we sure that we will find them
all, for that matter, before the release ?

Given the very strong insistence by n-m's proponents that these bugs
aren't even real, in many cases, it seems more likely that n-m will be
released in wheezy with infelicities which will be argued by the gnome
maintainers to be not bugs, or not rc, or someone else's fault.

For example, if I want to use ifupdown then I probably don't want n-m
to bring up even interfaces which exist but which I haven't mentioned
in /etc/network/interfaces - but managing those interfaces is
precisely the point of n-m.  So I'm cast back into "install n-m but
disable it", which is clearly inferior.

The result is surely going to be more friction between users who find
n-m doesn't work for them, and developers who insist on forcing n-m on
them.

It is very simple to avoid all of these kind of disagreements: allow
users to conveniently not have n-m if they don't want it.  It seems to
me unarguable that a user who doesn't want n-m should be allowed to
not have it, and still gain the other benefits of the metapackages
provided.

In all cases where removing the hard dependency (from the gnome
metapackage, in this case) makes any difference at all, it is to the
benefit of the user in question.  Assuming, as we should, that it is
to the benefit of a user who makes a conscious and informed decision
for that decision to be honoured even if some of us might not consider
it wise.

Our priorities are our users and free software.  How does pushing n-m
onto unwilling users benefit the users or free software ?

> It's certainly not the way I would do it,[1] but it's one way to
> mitigate the problems with unconditionally installing NM while
> allowing a further insistence that NM be installed which the gnome
> maintainers appear to strongly believe is necessary.

They do indeed appear to strongly believe that but they have advanced
no cogent reasons.  (You agree, don't you, that they haven't advanced
any cogent reasons?)

I have to say that the continued attempts to placate this unjustified
insistence are very perplexing to me, particularly given that the
"compromises" are:
 - clearly technically inferior
 - less respectful of our users' choices

The _only_ downside of my proposed decision is that it would annoy the
Debian gnome maintainers.  Our job however is to make technical
judgements on technical questions.  That doing the right thing would
annoy the maintainer, because the maintainer feels strongly but is
plainly wrong, is not a good reason for doing the wrong thing.

Ian.

-- 
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/20600.25487.202710.679...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Don Armstrong

On Fri, 12 Oct 2012, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > 1) we decide that failures of NM to detect basic ifupdown
> > configurations and avoid overriding them are bugs, possibly of RC
> > severity
> > 
> > 2) given the gnome maintainer's desire to have NM installed by default
> > from the gnome metapackage
> > 
> > allowing gnome to Depends: nm | wicd; would deal with the most
> > concerning form of breakage for me.
> > 
> > Does this work for anyone else?
> 
> Why do you think the gnome metapackage depending on, rather than
> recommending, wicd, is a good idea?

The primary case of NM breaking things is when it's installed with
wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.

> For example, consider the position of someone who has deliberately
> removed n-m in squeeze, and is using ifupdown or running ifconfig by
> hand or whatever, and upgrades to wheezy. This still gives them n-m
> back. That's not respecting their previous choice to remove it.

Right, but if they get NM back, and nothing breaks because of it,[0]
it's just the same as any other package being installed by a meta
package. They've wasted some disk space, and they've got another
program running, but everything continues to work.

It's certainly not the way I would do it,[1] but it's one way to
mitigate the problems with unconditionally installing NM while
allowing a further insistence that NM be installed which the gnome
maintainers appear to strongly believe is necessary.


Don Armstrong

0: This requires some buy-in by the NM maintainer(s), though.
1: But then, I don't run gnome, nor do I care to help maintain it.
-- 
As nightfall does not come at once, neither does oppression. In both
instances, there is a twilight when everything remains seemingly
unchanged. And it is in such twilight that we all must be most aware
of change in the air -- however slight -- lest we become unwitting
victims of the darkness.
 -- William O. Douglas

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20121012180512.gf7...@teltox.donarmstrong.com

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Chris Knadle

On Friday, October 12, 2012 11:30:36, Russ Allbery wrote:
> Jeremy Bicha  writes:
> > Not to put more ideas in Ian's head about packaging decisions to
> > overrule, but nobody objects to gnome-core depending on gdm, which also
> > starts by default after installation unless you explicitly disable it,
> > and conflicts with several other display managers that are part of
> > Debian.
> 
> That's the point, though.  No one objects.  In other words, we don't have
> a regular trickle of users of Debian stating that they want to disable
> gdm3 and use a different display manager while still wanting to use GNOME
> and expressing dissatisfaction with the metapackage because of it.  So
> there's no problem.

During an attempt to install a second X display manager, a question is asked 
during the inatall for which of the display managers is to be used to /avoid/ 
a conflict.  That's why there aren't complaints about gdm3 conflicting with 
kdm, xdm, wdm, etc -- if it did, there would be.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/201210121232.09061.chris.kna...@coredump.us

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Russ Allbery

Jeremy Bicha  writes:

> Not to put more ideas in Ian's head about packaging decisions to
> overrule, but nobody objects to gnome-core depending on gdm, which also
> starts by default after installation unless you explicitly disable it,
> and conflicts with several other display managers that are part of
> Debian.

That's the point, though.  No one objects.  In other words, we don't have
a regular trickle of users of Debian stating that they want to disable
gdm3 and use a different display manager while still wanting to use GNOME
and expressing dissatisfaction with the metapackage because of it.  So
there's no problem.  I personally have a lot of sympathy for Bdale's
position that metapackages would work better in general with Recommends,
but when no one's complaining, I'm certainly not going to poke my nose in
the GNOME team's business.

All three of the reasons in the original n-m decision are there for a
reason, and analogies to situations where one or more of those reasons
don't apply are not as relevant.

-- 
Russ Allbery (r...@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/878vbb7lnn@windlord.stanford.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Sam Hartman

I'm still confused why recommends doesn't work for everyone.

I understand that the Gnome maintainers want N-M installed by default.
Except I think recommends gets you that.


-- 
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/tslzk3rhkk4@mit.edu

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Raphael Hertzog

On Fri, 12 Oct 2012, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > 1) we decide that failures of NM to detect basic ifupdown
> > configurations and avoid overriding them are bugs, possibly of RC
> > severity
> > 
> > 2) given the gnome maintainer's desire to have NM installed by default
> > from the gnome metapackage
> > 
> > allowing gnome to Depends: nm | wicd; would deal with the most
> > concerning form of breakage for me.
> > 
> > Does this work for anyone else?
> 
> Why do you think the gnome metapackage depending on, rather than
> recommending, wicd, is a good idea ?  I don't really see the logical
> connection between any of the goals (whether the TC's or the GNOME
> maintainers') and your proposal.
> 
> For example, consider the position of someone who has deliberately
> removed n-m in squeeze, and is using ifupdown or running ifconfig by
> hand or whatever, and upgrades to wheezy.  This still gives them n-m
> back.  That's not respecting their previous choice to remove it.

The logic behind Don's proposition is that, if you're not using NM, then
you're likely either using wicd or simple ifupdown config. That leaves
two cases:

1/ Having wicd and nm active at the same time creates problems, so Don
ensures that you can install either one of them and still have the
gnome-core package installed (and still have nm by default if you don't
make any specific choice).

2/ If you're an ifupdown user, then you can have nm installed even if it
was not installed before hand, it won't hurt because NM ignores any
interface listed in /etc/network/interfaces. Failing to comply with this
rule are bugs that we could consider RC.

In this situation, it seems that all parties would be satisfied (provided
that the majority of persons who are not using NM are in fact using wicd
or ifupdown).

It looks like an acceptable outcome to me. Thank you Don for trying to find
a third way out of this situation.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

--
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/20121012133243.gg9...@x230-buxy.home.ouaza.com

Bug#688772: gnome Depends network-manager-gnome

2012-10-12 Thread Jeremy Bicha

On 12 October 2012 07:31, Ian Jackson  wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
>> 1) we decide that failures of NM to detect basic ifupdown
>> configurations and avoid overriding them are bugs, possibly of RC
>> severity
>>
>> 2) given the gnome maintainer's desire to have NM installed by default
>> from the gnome metapackage
>>
>> allowing gnome to Depends: nm | wicd; would deal with the most
>> concerning form of breakage for me.
>>
>> Does this work for anyone else?
>
> Why do you think the gnome metapackage depending on, rather than
> recommending, wicd, is a good idea ?  I don't really see the logical
> connection between any of the goals (whether the TC's or the GNOME
> maintainers') and your proposal.
>
> For example, consider the position of someone who has deliberately
> removed n-m in squeeze, and is using ifupdown or running ifconfig by
> hand or whatever, and upgrades to wheezy.  This still gives them n-m
> back.  That's not respecting their previous choice to remove it.

The point I took away from Chris' post is that wicd does not integrate
with GNOME Shell at all. There is only one networking solution that is
supported with GNOME 3.

Not to put more ideas in Ian's head about packaging decisions to
overrule, but nobody objects to gnome-core depending on gdm, which
also starts by default after installation unless you explicitly
disable it, and conflicts with several other display managers that are
part of Debian.

I consider a usable UI for setting up mobile networking (to include
WiFi) to be a fundamental piece of any desktop, especially GNOME.

I support Don's proposal to consider bugs where NM does not work right
with basic ifupdown configs to be RC-severity.

Jeremy

-- 
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/caaajcmzddazowmrqkcit9ec9uv-k1edo7mi3f9q_uuhc1yj...@mail.gmail.com

Bug#688772: gnome Depends network-manager-gnome

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 05 Oct 2012, Ian Jackson wrote:
> > Is there anyone who is unhappy with the draft below ?
> 
> I personally don't support 8, 9 and 10.

Losing 9 and 10 is fine by me if that gets your vote.

>  [I'd do something like 8, but I believe it assumes too much bad
> faith on the part of the gnome maintainers.]

Let me try to understand this position of yours more clearly:

You agree that the things prohibited by 8 are bad.  But you think the
gnome maintainers would certainly not do them.  Therefore spelling out
that they are forbidden is unnecessary and offensive.

So are you saying that we should leave off 8.  But if the gnome
maintainers do the bad things prohibted by 8, you would be happy to
overrule them a third time ?

I don't think that's wise but I'm willing to proceed on that basis if
that's what gets us some progress on this issue now.

No-one else has objected to my draft.  I'm therefore considering
proposing a vote; I would probably call for votes on two positive
resolutions:

  A  paras 1-7 of my previous draft
 gnome metapackage must not depend on n-m (3:1 required)

  B  1-8 of my previous draft
 as above, also prohibit backsliding (3:1 required)

Ian.

-- 
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/20600.568.542895.273...@chiark.greenend.org.uk

Bug#688772: gnome Depends network-manager-gnome