Discussion:
Bug#688772: gnome Depends network-manager-gnome
(too old to reply)
Ian Jackson
2012-10-05 17:09:54 UTC
Permalink
* ACTION: dondelelcaro to follow this up with the gnome maintainers to
get a clear argument from the GNOME maintainers about why this
*must* be a depends and not a recommends (dondelelcaro, 18:08:51)
I don't know if this was followed up, but there still doesn't seem to
be any such clear argument as far as I'm aware.

Here is a revised version of my draft resolution. I have incorporated
all the comments and weakened and/or removed the "political"
paragraphs dealing with the maintainers' behaviour. The only comment
I have rejected is the one suggesting a smaller version of what is now
para.8. I have introduced a new para.4 mentioning the lack of
convincing reasons for the dependency.

Is there anyone who is unhappy with the draft below ?

Ian.


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 wheey.

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 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.
Don Armstrong
2012-10-05 18:36:43 UTC
Permalink
Recommends are not enough to ensure that packages are installed,
especially upon upgrades. For example regarding NM, we definitely
*want* people who upgrade from squeeze to get NM installed.
What is still missing is the technical rationale for this desire. If
there were specific technical reason(s) why everyone who uses gnome
should have NM installed, then it would weigh more for forcing NM to
be installed if the gnome meta package was installed.

From what I know so far, the primary rationale appears to be that
gnome upstream considers NM part of gnome, and so it should be
installed. I believe the CTTE addressed this rationale in §2 of the
decision. We decided that unacceptable upgrade behavior outweighed
this, as outlined in §5 and §6.


Don Armstrong
--
Sometimes I wish I could take back all my mistakes
but then I think
what if my mother could take back hers?
-- a softer world #498
http://www.asofterworld.com/index.php?id=498

http://www.donarmstrong.com http://rzlab.ucr.edu
Don Armstrong
2012-10-05 18:43:14 UTC
Permalink
Post by Ian Jackson
* ACTION: dondelelcaro to follow this up with the gnome maintainers to
get a clear argument from the GNOME maintainers about why this
*must* be a depends and not a recommends (dondelelcaro, 18:08:51)
I don't know if this was followed up, but there still doesn't seem to
be any such clear argument as far as I'm aware.
I've followed up just now; had sort of been working out precisely what
I would like to say.
Post by Ian Jackson
Is there anyone who is unhappy with the draft below ?
I personally don't support 8, 9 and 10. [I'd do something like 8, but
I believe it assumes too much bad faith on the part of the gnome
maintainers.]


Don Armstrong
--
For a moment, nothing happened. Then, after a second or so, nothing
continued to happen.
-- Douglas Adams

http://www.donarmstrong.com http://rzlab.ucr.edu
Josselin Mouette
2012-10-05 23:08:07 UTC
Permalink
Hi Don,
Post by Don Armstrong
Recommends are not enough to ensure that packages are installed,
especially upon upgrades. For example regarding NM, we definitely
*want* people who upgrade from squeeze to get NM installed.
What is still missing is the technical rationale for this desire. If
there were specific technical reason(s) why everyone who uses gnome
should have NM installed, then it would weigh more for forcing NM to
be installed if the gnome meta package was installed.
The reason is that GNOME includes NM. Just like it includes gnome-shell
or whatever module. It’s not just an upstream decision: GNOME without NM
is a stripped down GNOME, with reduced functionality in many modules. We
consider GNOME as a tightly integrated environment, with components made
to work together. The metapackages are here to install this integrated
environment (which, despite that, differs from upstream on other
matters), and not just some random set of packages.

The code that makes it actually *work* without NM installed was added
for kFreeBSD – incidentally, by the same NM maintainer whose work has
been repeatedly thrown into mud in the discussions. His intent was
certainly not to give people an excuse to cripple down the Linux ports.
We do not consider this requirement to be optional on architectures
where it can be satisfied.
Post by Don Armstrong
From what I know so far, the primary rationale appears to be that
gnome upstream considers NM part of gnome, and so it should be
installed. I believe the CTTE addressed this rationale in §2 of the
decision. We decided that unacceptable upgrade behavior outweighed
this, as outlined in §5 and §6.
I disagree with the contents of §5 and §6. The release notes are here
precisely for this kind of cases. The reason why NM was only optional is
that historically (in lenny and before) it was buggy and wrongly
designed; which no longer applies.

The resolution also doesn’t mention which problems upgrading from a
squeeze system without NM to a wheezy system with NM causes. The cases
for potential breakage are rare (if they exist at all), and
administrators of systems with complicated network setups have all
reasons to read the release notes before upgrading blindly.

For these reasons, I consider resolution #681834 to be driven by
religious motives rather than technical ones, and that it was conducted
in haste. I have not said anything so far because the wording allows
(and again, I thought this was intentional) for the compromise to move
the dependency to the gnome package. But if people from either side
start questioning this compromise, I am afraid they are going to do a
lot of harm to the project.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Don Armstrong
2012-10-05 23:46:32 UTC
Permalink
Post by Josselin Mouette
The code that makes it actually *work* without NM installed was
added for kFreeBSD – incidentally, by the same NM maintainer whose
work has been repeatedly thrown into mud in the discussions.
So, besides the important goal of a complete gnome experience, there's
no other technical reason why NM must be installed?
Post by Josselin Mouette
I disagree with the contents of §5 and §6.
What in particular about §5 and §6?
Post by Josselin Mouette
The release notes are here precisely for this kind of cases.
This is certainly one of the possibilities that the CTTE (or a
maintainer) could proscribe to resolve this problem; I wouldn't be
averse to seeing an additional option proposed for a vote which did
just this.
Post by Josselin Mouette
The resolution also doesn’t mention which problems upgrading from a
squeeze system without NM to a wheezy system with NM causes.
"It attempts to avoid overriding local manual configuration, but it
isn't able to detect all cases where the user is using some other
component or system to manage networking."
Post by Josselin Mouette
For these reasons, I consider resolution #681834 to be driven by
religious motives rather than technical ones,
It's inflammatory to accuse others of having religious motives.[1] I
personally have no interest in punishing, persecuting, or otherwise
attacking the gnome maintainers or any other maintainer in Debian, and
I would be surprised if all of the other members of the CTTE don't
feel the same way.

We all want Debian to be a technically excellent distribution which
users want to use, and while we *often* have very different ideas on
what that actually means, we have come to those ideas by honest means.
Post by Josselin Mouette
and that it was conducted in haste.
I'm not sure if I would consider a two month long decision process
hasty, but since we seem to be doomed to readdress this issue again,
lets please try to make all of the arguments and solutions out front
so we can make a ideal decision.
Post by Josselin Mouette
I have not said anything so far because the wording allows (and
again, I thought this was intentional) for the compromise to move
the dependency to the gnome package.
I certainly didn't expect that to be a compromise position given the
underlying logic of the decision, and I certainly would have liked to
have addressed that point during the decision. I concede, however,
that it would be possible to construe the decision this way.
Post by Josselin Mouette
But if people from either side start questioning this compromise, I
am afraid they are going to do a lot of harm to the project.
We're all on the same side together.


Don Armstrong

1: Additionally, the negative connotation is offensive to the many
people who are involved in or use Debian who have religious beliefs.
--
-tommorow is our permanent address
and there they'll scarcely find us(if they do,
we'll move away still further:into now
-- e.e. cummings "XXXIX" _1 x 1_

http://www.donarmstrong.com http://rzlab.ucr.edu
Josselin Mouette
2012-10-06 00:32:33 UTC
Permalink
Post by Don Armstrong
Post by Josselin Mouette
The code that makes it actually *work* without NM installed was
added for kFreeBSD – incidentally, by the same NM maintainer whose
work has been repeatedly thrown into mud in the discussions.
So, besides the important goal of a complete gnome experience, there's
no other technical reason why NM must be installed?
Why would there be? The very purpose of metapackages is to define the
complete gnome experience. For other packages, dependencies indicate
what is required by what.
Post by Don Armstrong
Post by Josselin Mouette
I disagree with the contents of §5 and §6.
What in particular about §5 and §6?
* The affirmation that this will cause undesirable upgrade
behavior is grossly exaggerated.
* The reason for the historical Recommends instead of Depends is
not mentioned, while this history is used as an excuse for the
whole decision.
* The claim that NM can be replaced by another component without
functionality loss is preposterous.
* The excuse of the squeeze→wheezy upgrade serves as a basis for a
seemingly irrevocable decision that affects all future versions
of GNOME metapackages.
Post by Don Armstrong
It's inflammatory to accuse others of having religious motives.[1] I
personally have no interest in punishing, persecuting, or otherwise
attacking the gnome maintainers or any other maintainer in Debian, and
I would be surprised if all of the other members of the CTTE don't
feel the same way.
Yet you should wonder why there is such a broad consensus among GNOME
maintainers that NM should be a dependency, while most people pursuing
the goal of NM removal are not even GNOME users. I don’t think what we
do with GNOME affects autopkgtest, curl or hashalot.
Post by Don Armstrong
We all want Debian to be a technically excellent distribution which
users want to use, and while we *often* have very different ideas on
what that actually means, we have come to those ideas by honest means.
Ideally, yes. However I feel obliged to question the honesty of people
spreading misinformation before using this misinformation to request
CTTE decisions.
Post by Don Armstrong
Post by Josselin Mouette
But if people from either side start questioning this compromise, I
am afraid they are going to do a lot of harm to the project.
We're all on the same side together.
Looking at Ian’s last proposal, I’m afraid not.

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;

I’m having a hard time not seeing this as religious, but I’m ready to
listen to other explanations.
Post by Don Armstrong
1: Additionally, the negative connotation is offensive to the many
people who are involved in or use Debian who have religious beliefs.
People being offended because of their imaginary friend, just like
people being offended by at the idea of not developing Debian like
System V, are officially Not My Problem™.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Don Armstrong
2012-10-06 03:26:01 UTC
Permalink
Post by Josselin Mouette
Post by Don Armstrong
So, besides the important goal of a complete gnome experience,
there's no other technical reason why NM must be installed?
Why would there be?
If for example, network-manager was so inextricably linked to gnome
that it caused a particular kind of breakage such that it wasn't
reasonable for anyone who wanted the other gnome bits not have it
installed.
Post by Josselin Mouette
* The affirmation that this will cause undesirable upgrade behavior
is grossly exaggerated.
From what I understand, nm and wicd are not capable of co-existing.[1]
Furthermore, nm does not always catch that other systems (such as
ifupdown) are configuring the interfaces, and may lead to broken
behavior on upgrade (such as #656584 and #688355, just glancing at
it).
Post by Josselin Mouette
* The reason for the historical Recommends instead of Depends is
not mentioned, while this history is used as an excuse for the
whole decision.
What was the reason?
Post by Josselin Mouette
* The claim that NM can be replaced by another component without
functionality loss is preposterous.
Which functionality loss are we talking about? For simple
configurations, it seems quite possible to replace NM with ifupdown
with no loss of functionality.
Post by Josselin Mouette
* The excuse of the squeeze→wheezy upgrade serves as a basis for a
seemingly irrevocable decision that affects all future versions
of GNOME metapackages.
No CTTE decision is irrevocable. It's trivial to come back to the CTTE
and get us to sunset a decision. I personally would also not have had
a problem making this decision for the gnome meta packages only in
wheezy, with some transition plan to be worked out in the future.

Finally, in the future, please bring forward all of these concerns
about what the CTTE is deciding during the actual decision process so
we can address them.
Post by Josselin Mouette
I don’t think what we do with GNOME affects autopkgtest, curl or
hashalot.
It affects the users of Debian, which is what we're here for. [I'm
certainly not spending a nice Friday evening trying to sort this all
out for my own personal use of Debian.[2]]


Don Armstrong

1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#215
--
Live and learn
or die and teach by example
-- a softer world #625
http://www.asofterworld.com/index.php?id=625

http://www.donarmstrong.com http://rzlab.ucr.edu
Bdale Garbee
2012-10-06 04:07:10 UTC
Permalink
Post by Josselin Mouette
* The reason for the historical Recommends instead of Depends is
not mentioned, while this history is used as an excuse for the
whole decision.
I personally believe that metapackages should be primarily populated
with Recommends, with Depends largely reserved for actual technical
dependencies between real packages. This is consistent with my belief
that we should try to empower our users to be able to exercise a
reasonable amount of choice in configuring and operating their Debian
systems. Thus, my bias is to believe that when there's no strong
technical need, a Recommends is the appropriate choice, and any change
From a Recommends to Depends causes me to want to understand why the
change was made and what we hope to gain from it.
Post by Josselin Mouette
* The claim that NM can be replaced by another component without
functionality loss is preposterous.
I won't argue this point, since I use NM myself on my notebook because
it is the best fit for my needs at the moment of the available choices.
The degree to which using NM "entangles me" in other GNOME-related bits
that are not otherwise particularly useful to me is annoying, but a
burden I'm willing to bear because I like what NM does for me.
Post by Josselin Mouette
* The excuse of the squeeze→wheezy upgrade serves as a basis for a
seemingly irrevocable decision that affects all future versions
of GNOME metapackages.
I would personally like *all* metapackage maintainers to re-evaluate the
need for Depends vs Recommends in all future versions... this is
certainly not something in which *I* am personally trying to single out
GNOME.
Post by Josselin Mouette
Post by Don Armstrong
We all want Debian to be a technically excellent distribution which
users want to use, and while we *often* have very different ideas on
what that actually means, we have come to those ideas by honest means.
Ideally, yes. However I feel obliged to question the honesty of people
spreading misinformation before using this misinformation to request
CTTE decisions.
Regardless of what happens before, once an item is brought before the
CTTE, the only choice we all have is to try and make the discussion as
well-informed and balanced as possible, so that each CTTE member can
make the best possible decision given the information available.

We've already had some discussion about how much we should all as CTTE
members try to avoid bringing emotions into play. It is clear that Ian
has struggled with that on this issue, but that's precisely the reason
that we have a diverse committee that uses a voting process to make
decisions...

Bdale
Russ Allbery
2012-10-06 05:40:02 UTC
Permalink
Post by Josselin Mouette
* The claim that NM can be replaced by another component without
functionality loss is preposterous.
That's not what section 6 says. It says:

(ii) There is both demonstrable, intentional widespread replacement of
that package by Debian GNOME users and no significant loss of
unrelated GNOME desktop functionality by replacing it with a
different component.

You dropped the word "unrelated" in your objection, but I put that word in
there intentionally precisely because I think there *is* loss of
functionality, but it's functionality directly related to the decision
that the user is making.

There is clear loss of networking configuration functionality in GNOME by
removing Network Manager. But that's exactly the choice that the user is
making: giving up Network Manager network configuration functionality in
favor of something else. Presumably they're making an informed choice
about the value of the lost functionality to them, since it's directly
related to the component that they're replacing.

The situation would be considerably different if removing Network Manager
caused significant loss of *unrelated* functionality: functionality of the
desktop other than network configuration. Indeed, in that case I would
consider Depends to be entirely appropriate even for gnome-core.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Josselin Mouette
2012-10-06 07:41:53 UTC
Permalink
Post by Bdale Garbee
I personally believe that metapackages should be primarily populated
with Recommends, with Depends largely reserved for actual technical
dependencies between real packages.
This point is probably worth discussing because it comes up very often.

I don’t think it is reasonable to do so until metapackages are treated
differently by APT.
1. Removing them should not mark their dependencies autoremove.
2. A major upgrade (which is something that needs defining, especially
for testing/unstable users) should try to reinstall all dependencies or
ask, one way or another, whether the administrator still wants to
exclude them.
Basically this means going back to a tasks system from the current
metapackages situation (whether the implementation is based on packages
or not).
Post by Bdale Garbee
This is consistent with my belief
that we should try to empower our users to be able to exercise a
reasonable amount of choice in configuring and operating their Debian
systems.
Most of the time packages get removed, it is due to upgrade problems,
with APT not choosing the best solution. Strict dependencies alleviate
most of these problems.

Maybe you are unfamiliar with what clueless newbies do with their
systems. You want to empower users, that’s fine; but GNOME is for all
users. Those who have the technical knowledge to handle their packages
manually should also know how to make it happen without metapackages.
Post by Bdale Garbee
Thus, my bias is to believe that when there's no strong
technical need, a Recommends is the appropriate choice,
The purpose of a metapackage is to install all packages related to a
certain environment or functionality class. Let us not forget that when
choosing technical solutions.
Post by Bdale Garbee
and any change
From a Recommends to Depends causes me to want to understand why the
change was made and what we hope to gain from it.
What has changed since lenny is that NM has been rearchitectured and is
easy to disable. You cannot even treat it like it was the same piece of
software.
Therefore, this change was supposed to happen in squeeze, but we already
delayed it at that time because of upgrades from lenny, and because the
configuration format for system connections was still new and thus
unfamiliar to many.
If we delay it once again, what do we do for jessie?

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Chris Knadle
2012-10-06 11:22:43 UTC
Permalink
[…]
Post by Don Armstrong
Post by Josselin Mouette
* The affirmation that this will cause undesirable upgrade behavior
is grossly exaggerated.
From what I understand, nm and wicd are not capable of co-existing.[1]
As it has been mentioned that n-m had design issues that it may no longer
have, it means that /when/ I was having the issues I cited in the link above
with n-m may be important. I looked into my records, and the issues I was
having with n-m breakage on upgrades, n-m interfering with wicd, and upgrades
of n-m "undoing" user-made init script modifications to disable it occurred in
the Fall of 2009. Package/metapackage dependencies were also directly related
to why I was having the issue at the time too -- I remember trying to remove
n-m and found the system "fighting me" on it, and was too busy to work out how
to immediately get around the dependencies; I had the technical capability to
do so, but my focus needed to be elsewhere. Instead I kept having to use the
"field bandage" of re-modifying the init script after n-m broke the use of
wicd on each upgrade. IIRC I eventually ended up having to compromise and
remove certain programs I used and liked in order to remove n-m. wicd at that
time did not have a wicd-kde package, so I used wicd-gtk and wicd-curses; it
didn't matter much to me that these didn't integrate with the rest of the
system, because unlike n-m they didn't break on upgrades.

As I also mentioned [2], recent changes to the task-xfce-desktop package in
Wheezy pulled in n-m in a VM I run even though wicd had previously been
installed by default, and at least for the wired interface there didn't seem
to be a bad interaction.

I think my data on n-m is outdated, so I think more present-day testing of n-m
and wicd interaction is needed to know if any conflicts exist today.
Post by Don Armstrong
Post by Josselin Mouette
* The claim that NM can be replaced by another component without
functionality loss is preposterous.
Which functionality loss are we talking about? For simple
configurations, it seems quite possible to replace NM with ifupdown
with no loss of functionality.
One cited example: Phillip Kern mentioned [3] that n-m supports IPv6 where
wicd does not, which is why he had to switch back from wicd.



I'm not convinced by the argument of "functionality loss" compared to another
component as a reason for the Dependency. If an alternative works fine for
the user, I don't see why continuing to use it /shouldn't/ be allowed without
having to work-around the metapackage. I agree that n-m /does/ have
additional features to alternatives (and that it integrates better with
Gnome), but that still does /not/ mean that every user would want it or need
it. For instance there are often features n-m has that a user won't have the
capability of taking advantage of because they lack the hardware to do so.


I share Colin's concerns about having to work around the metapackage. Being
that Debian's mantra is "The /Universal/ Operating System", this implies that
it tries to cater to everyone, including those who my not yet have figured out
what reverse dependencies are and how to work around the metapackage at their
own risk. Removing one package and installing another is generally a
operation of a lower bar than working around a metapackage is. An interesting
situation to consider in this context is accidentily removing the network
configuration tool on a wireless-only system, and thus not having network
connectivity to install another one.

In addition my experience it's common to install several Window Managers and
Development Environments simultaneously on shared systems as well as users
wishing to try out the various choices; I think the dependency on n-m in the
gnome metapackage may impact that experience. It's of course also common to
run Gnome programs from a different DE or WM than Gnome, too. For both of
these reasons, the fact that the gnome metapackage is installed doesn't
necessarily mean Gnome is the primary environment being used.



I think this issue borders the gap between "user experience design" and
"allowing user choice by design". I believe the Gnome maintainers are looking
more towards the former, and I think the dependency has some impact on the
latter. I'm still not sure I understand the ramifications of a focus on the
latter; that is, what if any negative impact there would be if n-m was a
Recommends in the gnome metapackage.
Post by Don Armstrong
1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#215
2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#235

3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#255

-- Chris

--
Chris Knadle
***@coredump.us
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Chris Knadle
2012-10-09 09:09:15 UTC
Permalink
Post by Chris Knadle
[…]
Post by Don Armstrong
Post by Josselin Mouette
* The affirmation that this will cause undesirable upgrade behavior
is grossly exaggerated.
From what I understand, nm and wicd are not capable of co-existing.[1]
...
Post by Chris Knadle
I think my data on n-m is outdated, so I think more present-day testing of
n-m and wicd interaction is needed to know if any conflicts exist today.
I've retested this. If the network-manager daemon is running, I find that any
attempt to get wicd to connect to my wireless router fails with an error
message of "bad password". (Also tested all three wicd UIs.) Attempts
succeed once network-manager is stopped. After switching back to wired and
starting network-manager, attempts to connect to wireless via wicd once again
fail with the same error.
Post by Chris Knadle
Post by Don Armstrong
1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#215
-- Chris

--
Chris Knadle
***@coredump.us
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Don Armstrong
2012-10-23 22:16:42 UTC
Permalink
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
Sam Hartman
2012-10-24 01:29:43 UTC
Permalink
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.
Michael Biebl
2012-10-24 01:53:27 UTC
Permalink
Post by 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
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?
Andreas Barth
2012-10-24 07:57:07 UTC
Permalink
Post by Michael Biebl
Post by 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
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?
Post by Michael Biebl
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?
Post by Michael Biebl
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
Josselin Mouette
2012-10-24 08:38:26 UTC
Permalink
Post by Andreas Barth
Post by Michael Biebl
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?
Post by Andreas Barth
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
: :' :
`. `'
`-
Josselin Mouette
2012-10-24 08:51:49 UTC
Permalink
Let me comment on the proposals again.
Post by Ian Jackson
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.
Post by Ian Jackson
B 4. We overrule the decision of the meta-gnome maintainers to add a
B dependency from gnome to network-manager-gnome; this dependency
B should be replaced with a dependecy on network-manager-gnome (>=
B 0.9.4) | wicd.
Seriously, WTFF? Is it just a show-off option to make us think it’s
better to use a Recommends instead?
Post by Ian Jackson
B 5. Bugs in network-manager-gnome which break the functionality of
B existing /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…
Post by Ian Jackson
8. We specifically forbid anyone from introducing in wheezy, or
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?
Post by Ian Jackson
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.
Post by Ian Jackson
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
: :' :
`. `'
`-
Ian Jackson
2012-10-24 11:13:50 UTC
Permalink
Post by Michael Biebl
Post by 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
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.
Don Armstrong
2012-10-24 17:18:31 UTC
Permalink
Post by Ian Jackson
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
Ian Jackson
2012-10-24 17:26:48 UTC
Permalink
Post by Don Armstrong
Post by Ian Jackson
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.
Ian Jackson
2012-10-24 11:21:43 UTC
Permalink
Post by Josselin Mouette
Post by Ian Jackson
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 ?
Post by Josselin Mouette
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.
Post by Josselin Mouette
Post by Ian Jackson
B 4. We overrule the decision of the meta-gnome maintainers to add a
B dependency from gnome to network-manager-gnome; this dependency
B should be replaced with a dependecy on network-manager-gnome (>=
B 0.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.
Post by Josselin Mouette
And as for Ian’s hateful prose…
Post by Ian Jackson
8. We specifically forbid anyone from introducing in wheezy, or
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.
Ian Jackson
2012-10-24 11:23:27 UTC
Permalink
Post by Don Armstrong
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.
Post by Don Armstrong
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.
Bdale Garbee
2012-10-24 15:53:40 UTC
Permalink
Post by Josselin Mouette
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.
Post by Josselin Mouette
Post by Ian Jackson
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.
...
Post by Josselin Mouette
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.
Post by Josselin Mouette
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.
Post by Josselin Mouette
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
Don Armstrong
2012-10-24 17:13:54 UTC
Permalink
Post by Josselin Mouette
Post by Ian Jackson
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.
Post by Josselin Mouette
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.
Post by Josselin Mouette
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.
Post by Josselin Mouette
Post by Ian Jackson
B 4. We overrule the decision of the meta-gnome maintainers to add a
B dependency from gnome to network-manager-gnome; this dependency
B should be replaced with a dependecy on network-manager-gnome (>=
B 0.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.
Post by Josselin Mouette
Post by Ian Jackson
B 5. Bugs in network-manager-gnome which break the functionality of
B existing /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
Joerg Jaspert
2012-10-24 22:13:44 UTC
Permalink
Post by Josselin Mouette
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
<madduck> and yes, the ftpmasters are not the most clueful people
Josselin Mouette
2012-10-25 09:19:58 UTC
Permalink
Hi,
Post by Joerg Jaspert
Post by Josselin Mouette
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
: :' :
`. `'
`-
Don Armstrong
2012-10-25 16:17:59 UTC
Permalink
Post by Josselin Mouette
Post by Joerg Jaspert
Post by Josselin Mouette
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
Ian Jackson
2012-10-25 16:36:40 UTC
Permalink
Post by Don Armstrong
Post by Josselin Mouette
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.
Jeremy Bicha
2012-10-25 16:47:14 UTC
Permalink
Post by Don Armstrong
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
Bdale Garbee
2012-10-25 18:10:16 UTC
Permalink
Post by Jeremy Bicha
- 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.
Post by Jeremy Bicha
- 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.
Post by Jeremy Bicha
- 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.
Post by Jeremy Bicha
- 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! ;-)
Post by Jeremy Bicha
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
Andreas Barth
2012-10-25 20:47:01 UTC
Permalink
Post by Jeremy Bicha
Post by Don Armstrong
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.
1. Add a paragraph to the Release Notes with the one line command
"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
Michael Biebl
2012-10-25 22:27:58 UTC
Permalink
Post by Andreas Barth
Post by Jeremy Bicha
Post by Don Armstrong
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.
1. Add a paragraph to the Release Notes with the one line command
"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?
Chris Knadle
2012-10-26 12:19:46 UTC
Permalink
Post by Michael Biebl
Post by Andreas Barth
Post by Jeremy Bicha
Post by Don Armstrong
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.
1. Add a paragraph to the Release Notes with the one line command
"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
***@coredump.us
Don Armstrong
2012-10-26 17:02:22 UTC
Permalink
Post by Chris Knadle
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
Don Armstrong
2012-11-08 00:14:25 UTC
Permalink
Post by Michael Biebl
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
Raphael Hertzog
2012-11-08 07:35:06 UTC
Permalink
Hi,
Post by Michael Biebl
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/
Andreas Barth
2012-11-08 21:46:17 UTC
Permalink
Post by Ian Jackson
Therefore
A 4. We overrule the decision of the meta-gnome maintainers to add a
A dependency from gnome to network-manager-gnome; this dependency
A should be removed for the release of wheezy.
B 4. We overrule the decision of the meta-gnome maintainers to add a
B dependency from gnome to network-manager-gnome; this dependency
B should be removed for the release of wheezy. After the release of
B wheezy, if in the opinion of the NM maintainer the concerns
B raised in §4 of the CTTE decision #681834 have been addressed
B through technical means, the meta-gnome maintainers may freely
B adjust 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-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Don Armstrong
2012-11-08 22:05:04 UTC
Permalink
Post by Andreas Barth
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
B dependency from gnome to network-manager-gnome; this dependency
B should be [-removed for the release of wheezy. After the release of
B wheezy, if-] {+removed. If+} in the opinion of the NM maintainer {+(and
B before the release of wheezy the Release Managers)+} the concerns
B raised in §4 of the CTTE decision #681834 have been addressed
B through technical [-means,-] {+means (e.g. by preventing the starting of NM as
B discussed in #688772),+} the meta-gnome maintainers may freely
B adjust 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
Ian Jackson
2012-11-09 09:22:10 UTC
Permalink
Post by Don Armstrong
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.
Ian Jackson
2012-11-09 09:46:31 UTC
Permalink
Post by Ian Jackson
B 4. We overrule the decision of the meta-gnome maintainers to add a
B dependency from gnome to network-manager-gnome; this dependency
B should be [-removed for the release of wheezy. After the release of
B wheezy, if-] {+removed. If+} in the opinion of the NM maintainer {+(and
B before the release of wheezy the Release Managers)+} the concerns
B raised in §4 of the CTTE decision #681834 have been addressed
B through technical [-means,-] {+means (e.g. by preventing the starting of NM as
B discussed in #688772),+} the meta-gnome maintainers may freely
B adjust 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.
Andreas Barth
2012-11-09 11:27:23 UTC
Permalink
Post by Ian Jackson
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.)
Post by Ian Jackson
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.
Post by Ian Jackson
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
Don Armstrong
2012-11-09 18:09:10 UTC
Permalink
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
Ian Jackson
2012-11-09 18:41:08 UTC
Permalink
Post by Don Armstrong
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.
Post by Don Armstrong
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.
Post by Don Armstrong
Perhaps specifically spelling out what the
technical requirements are would be sufficient to mitigate the
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.
Post by Don Armstrong
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.
Don Armstrong
2012-11-09 19:07:08 UTC
Permalink
Post by Ian Jackson
Post by Don Armstrong
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.]
Post by Ian Jackson
Post by Don Armstrong
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.
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
Jordi Mallach
2012-11-13 09:19:18 UTC
Permalink
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 wicd binary is installed. A more full implemenation would of
course require modifications to the wicd package (and connman) as well.

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.

On behalf of the Debian GNOME team,
Jordi Mallach
Sjoerd Simons
Michael Biebl

[1] http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=shortlog;h=refs/heads/wip/debconf
--
Jordi Mallach Pérez -- Debian developer http://www.debian.org/
***@sindominio.net ***@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/
Ian Jackson
2012-11-13 11:14:59 UTC
Permalink
Post by Jordi Mallach
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.)
Post by Jordi Mallach
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.
Post by Jordi Mallach
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 ?
Post by Jordi Mallach
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.
Andreas Barth
2012-11-13 18:40:11 UTC
Permalink
Hi,
Post by Jordi Mallach
[...]
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.)
Post by Jordi Mallach
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.)
Post by Jordi Mallach
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
Noel David Torres Taño
2012-11-13 19:23:51 UTC
Permalink
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.
Post by 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.
I am a Gnome user, and I find Gnome without NM beyond acceptable: it is
perfectly usable. I'm using it to write this.
Post by Jordi Mallach
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.
Post by Jordi Mallach
Network manager is not an arbitrary requirement, even if GNOME Shell can
- 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.
Post by Jordi Mallach
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.
Post by Jordi Mallach
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.
Usage of Recommends for metapackages has been addressed in separated CTTE
issue #681783
Post by Jordi Mallach
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.
I fully agree. Also, I do not think this is an issue in current NM, unless NM
configures an inactive connection and thus renders the computer either
a) reachable via a non-intended network, previously down
b) change its routing table

Please note that I do not know if NM modifies the default gateway if it finds
and configures a previously unconfigured network card, but a) is a problem
anyway.
Post by Jordi Mallach
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.
I fully agree
Post by Jordi Mallach
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.
Correct. But this leaves unadressed the issue of explicit user decision to
have NM uninstalled even knowing it is a Recommends.
Post by Jordi Mallach
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.
Please think that there are users that want to stick with ifupdown/ifconfig
only.
Post by Jordi Mallach
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.
On behalf of the Debian GNOME team,
Jordi Mallach
Sjoerd Simons
Michael Biebl
[1]
http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=short
log;h=refs/heads/wip/debconf
Again, I want to thank you three for this coherent text and your effort to
settle this issue.

Regards

Noel Torres
er Envite

-------------------------
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?
Don Armstrong
2012-11-27 00:42:45 UTC
Permalink
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
B dependency from gnome to network-manager-gnome; this dependency
B should be removed. If in the opinion of the NM maintainer (and
B before the release of wheezy the Release Managers) the concerns
B raised in §4 of the CTTE decision #681834 have been addressed
B through technical means (e.g. by preventing the starting of NM as
B discussed in #688772), the meta-gnome maintainers may freely
B adjust the dependencies as usual.
B
B Specifically, valid bugs where existing valid network
B configurations are broken by the automatic, required installation
B on system upgrade of packages not previously installed which
B perform 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
Don Armstrong
2012-12-02 19:40:17 UTC
Permalink
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
A dependency from gnome to network-manager-gnome; this dependency
A should be removed for the release of wheezy.

B 4. We overrule the decision of the meta-gnome maintainers to add a
B dependency from gnome to network-manager-gnome; this dependency
B should be removed. If in the opinion of the NM maintainer (and
B before the release of wheezy the Release Managers) the concerns
B raised in §4 of the CTTE decision #681834 have been addressed
B through technical means (e.g. by preventing the starting of NM as
B discussed in #688772), the meta-gnome maintainers may freely
B adjust the dependencies as usual.
B
B Specifically, valid bugs where existing valid network
B configurations are broken by the automatic, required installation
B on system upgrade of packages not previously installed which
B perform 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
Russ Allbery
2012-12-02 20:16:17 UTC
Permalink
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 (***@debian.org) <http://www.eyrie.org/~eagle/>
Don Armstrong
2012-12-02 21:42:47 UTC
Permalink
Post by Russ Allbery
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
[...]

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.
Post by Russ Allbery
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
Russ Allbery
2012-12-02 21:54:08 UTC
Permalink
Post by Don Armstrong
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.
Post by Don Armstrong
I've gone ahead and updated the current don_draft.txt with this text
as written with the other options.
Thanks!
Post by Don Armstrong
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 (***@debian.org) <http://www.eyrie.org/~eagle/>
Bdale Garbee
2012-12-18 01:06:17 UTC
Permalink
I'd like to call for votes to resolve #688772
I vote CBAF.

Bdale
Andreas Barth
2012-12-18 17:50:39 UTC
Permalink
I'd like to call for votes to resolve #688772 with the following
options, with F as further discussion. Both options A and B require a
3:1 majority, as they overrule the gnome maintainers; Option C does
not.
I vote
BCAF


Andi
Colin Watson
2012-12-19 12:05:22 UTC
Permalink
I'd like to call for votes to resolve #688772 with the following
options, with F as further discussion. Both options A and B require a
3:1 majority, as they overrule the gnome maintainers; Option C does
not.
I vote BACF.
--
Colin Watson [***@debian.org]
Don Armstrong
2012-12-21 00:02:43 UTC
Permalink
Assuming I've done everything properly:

BACF don
CBFA rra
BCFA vorlon
ABCF ian
CBAF bdale
BCAF aba
BACF cjwatson

option A:F 5:2; does not beat majority requirements.
option B:F 7:0; beats majority requirements
option C:F 7:0; beats majority requirements

B:C 5:2
B:F 7:0
C:F 7:0

Option B is the winner.

Therefore the CTTE resolves:

=== 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

4. We overrule the decision of the meta-gnome maintainers to add a
dependency from gnome to network-manager-gnome; this dependency
should be removed. If in the opinion of the NM maintainer (and
before the release of wheezy the Chair of the Technical Committee
or an individual delegated by the Chair in consultation with the
Release Team) the concerns raised in §4 of the CTTE decision
#681834 have been addressed through technical means (e.g. by
preventing the starting of NM as discussed in #688772), the
meta-gnome maintainers may freely adjust the dependencies as
usual.

Specifically, valid bugs where existing valid network
configurations are broken by the automatic, required installation
on system upgrade of packages not previously installed which
perform 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.

=== STOP ===

By the time you read this, I should have updated the decision file in
the git repository. Please feel free to make changes to that before I
send out the announcement today or tomorrow.

I will also file a new bug against the gnome meta package with the
resolution when I publish the announcement.


Don Armstrong
--
Something the junk advertisers don't seem to understand: we live in an
information super-saturated world. If I don't want to buy something,
no amount of shouting or propagandizing will budge me; all it will do
is get me annoyed. On the other hand, if I have a need for your
product, I can seek it out in an eyeblink.
-- Charles Stross "Toast: A Con Report" in _Toast_ p136

http://www.donarmstrong.com http://rzlab.ucr.edu
Colin Watson
2012-12-19 11:44:45 UTC
Permalink
Is this a requirement for other network-providing packages as well? If
so, openvpn for instance is RC-buggy because upgrading it will restart
any configured VPNs. We don't require other packages to continue to
work uninterrupted during upgrades,
I think we actually do require that in some cases. OpenSSH, the X server,
and GDM come immediately to mind.
While nobody's ever told me that this is a requirement as such, I
consider it one on my own account as OpenSSH maintainer. It's just so
common to perform upgrades over SSH that I'd consider it irresponsible
to break that. (And fortunately the design of the OpenSSH server is
such that it tends to just work.)

For network-providing packages in general, I'd want to think about it
case by case, and I think it would depend on how common it is to perform
upgrades over the network interfaces they implement or support. openvpn
is commonly used, for instance, by people working at home to access
their employer's network, and in that case an interruption during
upgrade is not so important. If it's common to operate in reverse and
upgrade a system at the "client" end of an openvpn link, then that would
be a good argument for upgrading the severity of such a bug.

Some types of networking are just so rarely used as anything other than
a means of getting connectivity in network-poor locations that I would
have a very hard time arguing that their interruption during upgrades
could be release-critical. For instance, if a 3G network interface went
down during upgrade, or the client end of an IP-over-DNS link, then
that's ungraceful and could be handled more smoothly, but I don't think
it's RC.
--
Colin Watson [***@debian.org]
Continue reading on narkive:
Loading...