Re: Bug#681419: Alternative dependencies on non-free packages in main

[Goswin von Brederlow]

On Fri, Jul 13, 2012 at 09:59:33PM +0100, Ian Jackson wrote:
> Michael Gilbert writes ("Bug#681419: Alternative dependencies on non-free 
> packages in main"):
> > Perhaps the motivation behind this centers around FSF expectations on
> > Debian's handling of non-free?  If that is the case, wouldn't this
> > discussion be more appropriate on the new fsf-collab list?
> 
> How about instead we think about what the real issue is.  The FSF's
> view AIUI is that they want to avoid recommending (in the broadest
> sense) non-free software.  I think this is a reasonable objection, and
> it is one that we should be able to find some way to resolve.

I disagree there. The dependencies in a packages metadata are a technical
means of ensuring the software works. They are not a recommendation or
endorsement of said software in any way. As such no software in debian
"recommends" (in the FSF sense) non-free even if the dependencies state
that they can work with it or even needs it.

I think the issue here is that a technical means is used for a social means.

> It seems to me that there are two possible ways to do this:
> 
>  - Somehow change the package metatdata so that the reference to the
>non-free package lives in the non-free repo.

Depends: non-free/foo?
Depends: foo-non-free?
Depends: foo {non-free}?

I think all of those are bad. They only invite problems of getting out
of sync. Packages are known to have been moved between main/contrib/non-free
and then all reverse depends would have to be fixed.
 
>  - Change the packager UI, websites, etc. which interpret this data
>for users to not show references to non-free when they aren't
>wanted.

How is the UI to know what is non-free? Without the first change or
unless the admin has enabled non-free the package metadata does not
give any clue what packages are non-free. And if non-free isn't
wanted then why would anyone add it to sources.list?

So your two options don't apear to be "OR"s but appear to be an "AND".
 
MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120717082150.GA21400@frosties

Re: Bug#681419: Alternative dependencies on non-free packages in main

[Goswin von Brederlow]

On Fri, Jul 13, 2012 at 05:09:12PM -0600, Bdale Garbee wrote:
> Ian Jackson  writes:
> 
> > I think this is a real problem.  In general people sometimes find that
> > they need to enable non-free for some particular reason (perhaps even
> > just too make their nic work or something).   That shouldn't mean
> > that their system becomes tainted willy-nily with non-free stuff.
> 
> I completely agree.
> 
> Bdale

The current solution to this is pinning. But ...

Currently the repository only has 2 types in the Release file: Automatic
yes and no. Maybe it is time to add a third that would cause frontends to
avoid installing any new package of that type and ask before installing
if they must to resolve some dependency conflict.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120717083004.GB21400@frosties

Re: Draft GR for permitting private discussion

[Stefano Zacchiroli]

On Mon, Jul 16, 2012 at 12:01:50PM -0400, Michael Gilbert wrote:
> As an example, the wine package was in a very similar state to the
> python package a few months back.  Instead of complaining about the
> maintainer (and likely leading to a flamewar), I did my best to get
> work done while concurrently allowing the maintainer to reject that
> work if he were really interested.  This involved many 10-day delayed
> liberal nmus of the package, culminating in bringing it up to date.  I
> also ensured that all of my messages were positive, and acknowledged
> the fact that the maintainer could review and reject the nmus while
> they were in delayed.  Apparently, my uploads were sufficient and none
> were rejected.  Ultimately, I brought the package up to date, and was
> accepted in to the team.
> 
> This worked, I believe, because I maintained a positive stance
> throughout the process.

Let's add a couple of data points to this example of yours. IIRC the
timeline, before your involved in it, I chimed in the relevant buglog
suggesting, if not encouraging, the NMU path. Later on you contacted me,
privately, asking for advice on the best way to proceed with the NMUs.
I've been happy to provide the advice, essentially encouraging your
NMU-based plan (my position towards NMUs is well known, so that should
come to no surprise to anyone). Then you proceeded, cautiously, doing
very proper NMUs that allowed, together with some help from the
maintainer later on (I'm thinking at alioth permissions here) to solve
the issue for Wheezy. Which is a great result.

But I still find interesting that in an example that you use to argue
for transparency, a private mail exchange has played a relevant role.



Transparency is hard. But it is a worthwhile goal. Out of hypocrisy, I
suspect that today every non trivial (social) conflict solving will end
up having some private exchanges. Especially when mediations are needed.
The question we should ask ourselves, then, is how to *minimize* those
exchanges. Ideally trying to reduce them to 0 even if we know we're not
there yet.

This is why I'm worried about this specific GR: it seems to go in the
opposite direction. I think that the present situation, i.e. "thou shalt
not do that", is a moral check on the desire of discussing matters
privately with and within the tech-ctte. Those private discussions will
happen [1], but the fact that they are considered socially wrong will
limit them to cases that are considered "extreme", even for tech-ctte
issues (which are already extreme per se). I fear that legitimating
private discussions will remove this useful moral check.

I realize that my stance above is a hack, based on the assumption that
people will occasionally "break rules" even if they shouldn't. And I
understand that the draft GR is trying to attack the problem from the
opposite angle, i.e. defining when private tech-ctte discussions are
acceptable. But the propose solution seems flawed in at least two ways.
The first one is that once easy mechanisms for discussing privately are
in place (e.g. a debian-ctte-private list), it will come very naturally
to discuss privately also matters that could've been discussed publicly.
The second one is that nobody outside the tech-ctte will be able to
control what is actually being discussed on those fora.

The tech-ctte is a trusted body in Debian anyhow and, presently, I have
no reason to distrust any single member of the tech-ctte. But removing
both the moral check of discussing matters publicly and the ability to
review what is going on doesn't seem wise. It is after all the kind of
paranoia that comes handy when designing constitution-like documents.
(One might argue that a similar problem exists with the leader@d.o
mailbox, and I agree with that. But at least the DPL is subject to
periodic reelections, which is not the case for tech-ctte members.)


As some sort of more positive conclusion, I encourage the tech-ctte to
go ahead with this GR. It is a very important matter on which a vote
should have a final say. But if you want for it some chances of success,
I think you should be more clear on the desire of limiting private
discussions to the very minimum. For one thing, I think "[public]
discussion" in the title of the constitution paragraph should stay.
Similarly, I don't find the usage of "infeasible" and
"counterproductive" reassuring enough. Especially the latter is very
subjective (who decides it?) and might be used to legitimate all sorts
of private discussions.


With many thanks for all the work the tech-ctte is putting in fixing
Constitution "bugs" here in there, it's much appreciated.

Cheers.

[1] for full disclosure, I remind here that I've pleaded guilty for
having done so myself ~24 hours before submitting #658341, asking
for comments on my draft bug report
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de confé

Re: Bug#681419: Alternative dependencies on non-free packages in main

[Ian Jackson]

Goswin von Brederlow writes ("Re: Bug#681419: Alternative dependencies on 
non-free packages in main"):
> On Fri, Jul 13, 2012 at 09:59:33PM +0100, Ian Jackson wrote:
> > How about instead we think about what the real issue is.  The FSF's
> > view AIUI is that they want to avoid recommending (in the broadest
> > sense) non-free software.  I think this is a reasonable objection, and
> > it is one that we should be able to find some way to resolve.
> 
> I disagree there. The dependencies in a packages metadata are a technical
> means of ensuring the software works.

I think we are actually mostly in agreement.  I certainly agree that
there is a distinction between technical implementation and UI
presentation and that we're probably mostly worried about the latter.

>  They are not a recommendation or endorsement of said software in
> any way. As such no software in debian "recommends" (in the FSF
> sense) non-free even if the dependencies state that they can work
> with it or even needs it.

Well the is no software in Debian with dependencies which "state that
[it] needs" non-free software.  We have some software which states
that "it needs some facility which can be provided by both free and
non-free software".

I also think it's disingenuous to say "`Recommends:' does mean
recommends".  The entire point here is one about social political
stuff including perceptions, and you can't just dismiss these kind of
words as an implementation detail - they are highly visible.

But that doesn't mean that we have to do terrible violence to our
system to fix the problem.

> I think the issue here is that a technical means is used for a social means.

That's what technical means are _for_.  IMO.


> > It seems to me that there are two possible ways to do this:
> > 
> >  - Somehow change the package metatdata so that the reference to the
> >non-free package lives in the non-free repo.

I wrote this alternative not because I thought it was a good idea but
because it was logically possible and therefore it was necessary to
discuss it.  But this...

> Depends: non-free/foo?
> Depends: foo-non-free?
> Depends: foo {non-free}?

...isn't in that category.  What I was talking about was this:

   Package: foo
   Recommends: bar

   Package: bar
   Section: barthingies

   Package: bar-nonfree
   Section: nonfree/barthingies
   Do-Some-Weird-Thing: bar.Recommends =~ s/bar/bar | bar-nonfree/

This would be logically possible but I think it would be a bad idea.

But in many cases this could be achieved with:

   Package: bar-nonfree
   Section: nonfree/barthingies
   Provides: bar

which would avoid the need for these out-of-main references.


> >  - Change the packager UI, websites, etc. which interpret this data
> >for users to not show references to non-free when they aren't
> >wanted.
> 
> How is the UI to know what is non-free? Without the first change or
> unless the admin has enabled non-free the package metadata does not
> give any clue what packages are non-free. And if non-free isn't
> wanted then why would anyone add it to sources.list?

As I wrote earlier:

  I think this is a real problem.  In general people sometimes find that
  they need to enable non-free for some particular reason (perhaps even
  just too make their nic work or something).   That shouldn't mean
  that their system becomes tainted willy-nily with non-free stuff.

> So your two options don't apear to be "OR"s but appear to be an "AND".

If the metadata available to the package manager were sufficient, it
could avoid using unwanted non-free dependency arms.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20485.19173.806988.92...@chiark.greenend.org.uk

Bug#681419: Alternative dependencies on non-free packages in main

[Ian Jackson]

Russ Allbery writes ("Bug#681419: Alternative dependencies on non-free packages 
in main"):
> Well, if we want to go this route, we could require use of a virtual
> package in all cases like this.  Then foo and foo-nonfree would both
> Provide: foo (and probably Conflicts: foo), and those who want to can
> enable non-free and install foo-nonfree.
> 
> That was one of the options offered in the Policy discussion.

Do we know what proportion of the existing references out of main into
non-free/contrib could be done this way ?

That would at least solve the problem where we put
   Recommends: ... | bar-nonfree ...
in the metadata, which I think is arguably a problem in itself.  It's
difficult to argue that that doesn't constitute a recommendation of
bar-nonfree.

Would we also want to do something to avoid the package managers
complaining about nonexistent virtual packages ?  I guess they are
already happy to ignore references to unprovided virtual packages, and
nonexistent packages in general, since they are a common approach for
transitions and often remain (beneficially) in the dependencies for
years afterwards.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20485.19667.646721.533...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

block 645656 by 681834
thanks

The argument about the dependency from gnome-core to network-manager
has now reached the TC.  This has been extensive discussed, most
recently on debian-devel.  The most recent response from Josselin is
here:
  http://lists.debian.org/debian-devel/2012/07/msg00210.html

It seems to me that:

 * n-m breaks the networking of enough people that this is a
   significant problem which should be fixed.

 * There is not currently another metapackage besides gnome-core that
   would pull in enough of the gnome system.

 * There is no good reason not to use Recommends (or indeed Suggests)
   in a metapackage.

 * In particular, tests have shown that the remainder of gnome
   functions as expected when network-manager is not installed; the
   situation appears to be the similar to that which occurs if n-m is
   installed but the system's active network connection is not one
   made by n-m.

 * Also, that there are people who choose not to install Recommends at
   all is not a reason not to make this change.

 * The present situation in wheezy appears to be a regression from
   squeeze.

So I would propose that we:

 * Clarify our view that the normal rules for deciding dependency
   priorities apply to meta packages too;

 * Require no change to policy;

 * Overrule the maintainer of gnome-core, requiring that the
   dependency on network-manager be changed to Recommends;

 * Advise the release managers that we would prefer this change to be
   made in wheezy, provided it is uploaded promptly.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20485.24845.608999.23...@chiark.greenend.org.uk

Processed: Bug#681834: network-manager, gnome, Recommends vs Depends

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 645656 by 681834
Bug #645656 [gnome-core] gnome-core: please re-soften the network-manager-gnome 
dependency
645656 was not blocked by any bugs.
645656 was not blocking any bugs.
Added blocking bug(s) of 645656: 681834 and 681783
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
645656: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645656
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.1342534455456.transcr...@bugs.debian.org

Bug#681834: network-manager, gnome, Recommends vs Depends

[Gergely Nagy]

Ian Jackson  writes:

>  * There is no good reason not to use Recommends (or indeed Suggests)
>in a metapackage.

I'd like to respectfully disagree here - though I've tried to express
this on debian-devel@ too, apparently, with little success.

As a user, my expectation is that if I install a *meta* package, then
the whole platform will be installed, and will be kept installed. That's
the main reason I install meta packages.

With recommends, it's not particularly hard to end up in a situation
where parts of the platform get forced off, and they're not going to
come back unless explicitly asked. "What's this gstreamer thing? Never
heard of it, lets remove it. Oh, look, there goes totem. WTF was that
thing again? Probably not important, otherwise it wouldn't get removed,
would it?" - exaggeration of course, but this is not very different from
the situation where removing n-m wants to remove gnome and all the rest
too. Except that currently, it's easier to notice that something bad is
about to happen, and ask first. With recomends, bad things can happen
with far less scarier warnings.

I believe that's a very bad situation, and while possibly avoidable in
stable, and even in oldstable->newstable dist-upgrade paths (at least
the case where a part of the recommended set would be forced off for one
reason or the other) unstable users (and testing users, until testing
migration will consider recommends) will likely experience hiccups
during a transition for example.

Granted, testing/unstable users should be prepared to deal with issues,
but if we can avoid pissing them off, we should.

>  * The present situation in wheezy appears to be a regression from
>squeeze.

Depends on who you ask. Many will consider gnome3 to be a regression
too.

> So I would propose that we:
>
>  * Clarify our view that the normal rules for deciding dependency
>priorities apply to meta packages too;
>
>  * Require no change to policy;
>
>  * Overrule the maintainer of gnome-core, requiring that the
>dependency on network-manager be changed to Recommends;
>
>  * Advise the release managers that we would prefer this change to be
>made in wheezy, provided it is uploaded promptly.

How about a solution suggested earlier on debian-devel@? At least one of
the Gnome maintainers showed interest in something like this:

  * Introduce a gnome-minimal (or any other, more suitable name, really)
meta package, that depends on a subset of what gnome-core depends
now (and which would not include n-m). And gnome-core would depend
on this + additional stuff.

With this, the major complaint (n-m) is solved, policy does not have to
change, nor do we need to overrule any maintainers.

To me, this sounds like a much better idea, with less impact overall,
yet, still addressing the biggest issue.

Obviously, I'm biased and all that, but this was needed to be told. To
avoid turning this bug report into the same thing that became of the
thread on -devel, this is my first and last message here.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vchmxz2t.fsf@algernon.balabit

Re: Bug#681419: Alternative dependencies on non-free packages in main

[Bdale Garbee]

Goswin von Brederlow  writes:

> Currently the repository only has 2 types in the Release file: Automatic
> yes and no. Maybe it is time to add a third that would cause frontends to
> avoid installing any new package of that type and ask before installing
> if they must to resolve some dependency conflict.

That's a very interesting thought...

Bdale


pgpeyUChMEMgQ.pgp
Description: PGP signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Bdale Garbee]

Ian Jackson  writes:

> The argument about the dependency from gnome-core to network-manager
> has now reached the TC. 

FWIW, I use network-manager with xfce4 on my notebook, and with suitable
configuration find it an acceptable solution for my needs.

As a matter of policy, though, it seems completely unreasonable to me
for a desktop environment to impose a hard decision on something like
network attachment and configuration where there are multiple workable
alternatives in Debian that users might reasonably expect to be able to
exercise personal preference on.

> So I would propose that we:
>
>  * Clarify our view that the normal rules for deciding dependency
>priorities apply to meta packages too;

Agreed.

>  * Require no change to policy;

Agreed.

>  * Overrule the maintainer of gnome-core, requiring that the
>dependency on network-manager be changed to Recommends;

That would work.  

I believe our goal should be to require that there not be a hard Depends
relationship.  I would be equally satisfied if the dependency were just
dropped, or if it were possible to craft a suitable "or" list of
alternatives that network-manager could be the first choice of the
maintainer among.  I have not followed the discussion closely enough or
independently studied this situation in sufficient detail to know if
this is possible, however.

>  * Advise the release managers that we would prefer this change to be
>made in wheezy, provided it is uploaded promptly.

Agreed.

Bdale


pgplPSSEEQ3u1.pgp
Description: PGP signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Bdale Garbee]

Gergely Nagy  writes:

> Ian Jackson  writes:
>
>>  * There is no good reason not to use Recommends (or indeed Suggests)
>>in a metapackage.
>
> I'd like to respectfully disagree here - though I've tried to express
> this on debian-devel@ too, apparently, with little success.
>
> As a user, my expectation is that if I install a *meta* package, then
> the whole platform will be installed, and will be kept installed. That's
> the main reason I install meta packages.

I comprehend you, but to me the difficulty is in defining what "the
whole platform" means and thus where the boundary should lie.  In the
current case, if someone says "I want Gnome", do they really expect that
to include network-manager to the exclusion of all other options, or
might they reasonably expect to be able to use wicd, or something else,
as an alternative? 

> How about a solution suggested earlier on debian-devel@? At least one of
> the Gnome maintainers showed interest in something like this:
>
>   * Introduce a gnome-minimal (or any other, more suitable name, really)
> meta package, that depends on a subset of what gnome-core depends
> now (and which would not include n-m). And gnome-core would depend
> on this + additional stuff.
>
> With this, the major complaint (n-m) is solved, policy does not have to
> change, nor do we need to overrule any maintainers.

As a resolution to the specific issue at hand, I think I'd find this
acceptable.  However, it feels like a more disruptive change than just
flipping the Depends in question to Recommends, so I'm not immediately
convinced it's a *better* choice. 

Bdale


pgpG0SdI6SPDf.pgp
Description: PGP signature

Bug#681687: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).

[Laszlo Boszormenyi (GCS)]

Answering to my own mail.

On Tue, 2012-07-17 at 05:38 +, Laszlo Boszormenyi (GCS) wrote:
> On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote:
> > 2) Install in Alioth's collab-maint a git repository made with the --debsnap
> >option of git-import-dscs, unless we try to go deeper in time ?  Set up
> >commits emails to go to the PTS.
>  I've created an empty git collab-maint repository on Alioth, still not
> visible over the web interface. As I know, it just need some time.
 It is now visible:
http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=summary
Empty at the moment. I used git-debimport , the result is at GitHub for
review: https://github.com/gcsideal/mime-support
If it's OK, I'll rebase to git.debian.org .

Regards,
Laszlo/GCS


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

Bug#681419: Alternative dependencies on non-free packages in main

[Russ Allbery]

Ian Jackson  writes:

> Do we know what proportion of the existing references out of main into
> non-free/contrib could be done this way ?

I'm not sure; we'd have to check.  However, it seems like it should handle
all of them except any that would need a versioned dependency.

> That would at least solve the problem where we put
>Recommends: ... | bar-nonfree ...
> in the metadata, which I think is arguably a problem in itself.  It's
> difficult to argue that that doesn't constitute a recommendation of
> bar-nonfree.

> Would we also want to do something to avoid the package managers
> complaining about nonexistent virtual packages ?  I guess they are
> already happy to ignore references to unprovided virtual packages, and
> nonexistent packages in general, since they are a common approach for
> transitions and often remain (beneficially) in the dependencies for
> years afterwards.

The only dependencies on non-free from main right now are in the form of
an alternative between a free package and a non-free package (or are
serious bugs), I believe.  So I don't think any of the virtual packages
would be non-existent, since the free package would always provide that
virtual package, no?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87liiibauf@windlord.stanford.edu

Bug#681419: Alternative dependencies on non-free packages in main

[Ian Jackson]

Russ Allbery writes ("Bug#681419: Alternative dependencies on non-free packages 
in main"):
> Ian Jackson  writes:
> > Would we also want to do something to avoid the package managers
> > complaining about nonexistent virtual packages ?  I guess they are
> > already happy to ignore references to unprovided virtual packages, and
> > nonexistent packages in general, since they are a common approach for
> > transitions and often remain (beneficially) in the dependencies for
> > years afterwards.
> 
> The only dependencies on non-free from main right now are in the form of
> an alternative between a free package and a non-free package (or are
> serious bugs), I believe.  So I don't think any of the virtual packages
> would be non-existent, since the free package would always provide that
> virtual package, no?

Very good point.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20485.38944.494580.726...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Bdale Garbee writes ("Re: Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> Ian Jackson  writes:
> >  * Overrule the maintainer of gnome-core, requiring that the
> >dependency on network-manager be changed to Recommends;
> 
> That would work.  
> 
> I believe our goal should be to require that there not be a hard Depends
> relationship.  I would be equally satisfied if the dependency were just
> dropped, or if it were possible to craft a suitable "or" list of
> alternatives that network-manager could be the first choice of the
> maintainer among.  I have not followed the discussion closely enough or
> independently studied this situation in sufficient detail to know if
> this is possible, however.

That's a fine way to put the requirement.  But given that we can't
mandate that the maintainer makes the upload we should give explicit
blessing to weakening the dependency rather than doing something else,
so that someone who NMUs knows what they're doing.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20485.38857.97183.721...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Bdale Garbee writes ("Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> Gergely Nagy  writes:
> > As a user, my expectation is that if I install a *meta* package, then
> > the whole platform will be installed, and will be kept installed. That's
> > the main reason I install meta packages.
> 
> I comprehend you, but to me the difficulty is in defining what "the
> whole platform" means and thus where the boundary should lie.  In the
> current case, if someone says "I want Gnome", do they really expect that
> to include network-manager to the exclusion of all other options, or
> might they reasonably expect to be able to use wicd, or something else,
> as an alternative? 

Quite.

It has also been suggested that gnome-session would be a better
package to install, but of course that excludes all of the gnome
applications - which is probably what the user wanted in this case.

> > How about a solution suggested earlier on debian-devel@? At least one of
> > the Gnome maintainers showed interest in something like this:
> >
> >   * Introduce a gnome-minimal (or any other, more suitable name, really)
> > meta package, that depends on a subset of what gnome-core depends
> > now (and which would not include n-m). And gnome-core would depend
> > on this + additional stuff.
> >
> > With this, the major complaint (n-m) is solved, policy does not have to
> > change, nor do we need to overrule any maintainers.

Policy does not need to change in any case.  There is nothing
forbidding the use of Recommends, or indeed any mixture of dependency
strengths, in metapackages.

> As a resolution to the specific issue at hand, I think I'd find this
> acceptable.  However, it feels like a more disruptive change than just
> flipping the Depends in question to Recommends, so I'm not immediately
> convinced it's a *better* choice. 

In particular, users who already have gnome-core installed, and have
previously overridden the installation of network-manager, will find
that the upgrade brings in network-manager.

I think preserving the choice of users who have done this is
important, and whatever is done should achieve that goal.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20485.39256.773294.15...@chiark.greenend.org.uk

Re: Draft GR for permitting private discussion

[Russ Allbery]

Stefano Zacchiroli  writes:

> But I still find interesting that in an example that you use to argue
> for transparency, a private mail exchange has played a relevant role.

I don't find this at all surprising.  In fact, I would be stunned if this
isn't the case in most such situations.

I probably should save this for the main discussion in -vote or -project,
but since I'm thinking about it right now, I may as well say it here so
that I have it all written down.  I will plan on rewording and repeating
this later as part of the broader discussion.

> This is why I'm worried about this specific GR: it seems to go in the
> opposite direction. I think that the present situation, i.e. "thou shalt
> not do that", is a moral check on the desire of discussing matters
> privately with and within the tech-ctte. Those private discussions will
> happen [1], but the fact that they are considered socially wrong will
> limit them to cases that are considered "extreme", even for tech-ctte
> issues (which are already extreme per se). I fear that legitimating
> private discussions will remove this useful moral check.

There are two different things that you can happen when you say something
that's obviously infeasible in a procedural document like the
constitution.  One is, as you say, that it will serve as a moral force to
make violations of that principle rare and "extreme."  The other is to
make the rules of the document look ridiculous and cause them to lose all
moral force entirely.

I believe the current situation is the latter, not the former.

The idea that any decision-making body would avoid all discussions in
private is, to me, completely contrary to how people interact and how
every decision-making body that I've ever heard of functions.  I've never
heard of a body akin to the technical committee that operates under those
sorts of absolute constraints: not corporate boards, not project oversight
groups in corporations, not free software governance organizations, not
governments, not non-profit committees.  The only exception that I can
think of off-hand are Olympic judges, where the point of that sort of rule
is to prevent collusion between the judges to generate a particular
outcome.  I certainly hope people don't think that's analogous to the work
of the technical commitee!

The current wording, read literally, means that if I happened to run into
Steve Langasek, say, at a social occasion, I am not permitted to mention
network-manager and GNOME to him, because that conversation isn't public
and that's an issue currently before the technical committee.  I'm not
allowed to talk about network-manager in a private Usenet hierarchy that I
happen to know that Colin Watson and Ian Jackson also read because that's
not public.  It feels like I'm expected to act like a prospective US
Supreme Court judge whose nomination is before Congress: I must not say
anything about anything, ever!

I don't believe that technical committee members have ever actually
behaved this way.  By the very nature of the role, the people on the
technical committee generally know each other and generally have other
contact outside of committee work, and the topics that come before the
committee are generally topics of considerable discussion in the project.
They are therefore natural topics of discussion, and this sort of absolute
ban is horribly distortive and very difficult to achieve.

And to what end?  Certainly, this sort of extreme limitation on discussion
isn't going to result in better decisions.  Part of my decision-making
process, and I don't think this is unique to me, is to mull something over
from multiple angles, bounce it off of people, and seek out different
perspectives.  Depending on the issue, or depending on simple
*convenience*, some of those discussions will be effectively private.  It
helps in getting as broad of input as possible, including from people who
may not be comfortable expressing their opinion in public when they
believe their opinion to be unpopular or when they feel like they'll get
shouted down.  (And yes, to me this does go to honoring diversity.)

I believe the underlying goal here, which we need to preserve, is that the
reasons for the decisions of technical committee members must be made
public: that we state our reasoning for our votes for the record and in a
forum where other people can see and comment if they believe that
reasoning is ill-considered.  I also think that enough of the
deliberations need to be public for the project as a whole to monitor and,
if necessary, check committee members who are making decisions on bases
that might harm the project.  We certainly do not want to be in a
situation where the committee hands down unjustified opinions, where the
only public artifact of the decision is a vote.  And I support finding
some way to say that in the constitution.

But this sort of outright ban is not how one does it.  Rather, I would
instead look to a model where there are formal meetings a

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Bdale Garbee writes ("Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> I believe our goal should be to require that there not be a hard Depends
> relationship.  I would be equally satisfied if the dependency were just
> dropped, or if it were possible to craft a suitable "or" list of
> alternatives that network-manager could be the first choice of the
> maintainer among.  I have not followed the discussion closely enough or
> independently studied this situation in sufficient detail to know if
> this is possible, however.

Thinking about this some more, I think it would be better to mandate
a specific solution.

There have been many suggestions of alternative approaches which are
(i) more complicated and (ii) whose effects we are not entirely sure
and (iii) which would require specifying in detail, but which somehow
avoid sidestep the key disputes.

The key disputes seem to be:

  - Some people claim that metapackages should not use Recommends.
I disagree.

  - GNOME upstream have declared Network Manager to be an integral
part of GNOME and the Debian maintainer is insisting on following
their lead in gnome-core.  The maintainer is essentially asserting
that the very purpose of the gnome-core metapackage is to reflect
precisely what upstream have decreed, and that we should not
deviate.  I disagree; I think (a) we should feel free to deviate
from upstream if doing so is better for our users and (b) anyway
setting one of the dependencies to Recommends is not a significant
deviation.

My best argument in favour of specifying the specific solution is that
we know exactly what the effects will be.

If we want instead to write a resolution specify the effects, we will
have to consider carefully exactly which effects we want to mandate.
For example, creating another metapackage might have transitional
implications; both for users upgrading from squeeze and for other
packages which depend on gnome-core.

Also if we want this to be in wheezy we want not to be messing about
with complicated solutions.  There is a risk, for example, that the
maintainer might choose an approach unsuitable for release in wheezy.
We can hardly tell the maintainer `you must do this but you must do it
in the way you think is best for wheezy' - that would amount to asking
them to undermine their own judgement.

For the same reason I would like a decision quickly.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20485.40374.796219.791...@chiark.greenend.org.uk

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Noel David Torres Taño]

On Martes, 17 de julio de 2012 16:39:47 Bdale Garbee wrote:
> Gergely Nagy  writes:
[...]
> > How about a solution suggested earlier on debian-devel@? At least one of
> > 
> > the Gnome maintainers showed interest in something like this:
> >   * Introduce a gnome-minimal (or any other, more suitable name, really)
> >   
> > meta package, that depends on a subset of what gnome-core depends
> > now (and which would not include n-m). And gnome-core would depend
> > on this + additional stuff.
> > 
> > With this, the major complaint (n-m) is solved, policy does not have to
> > change, nor do we need to overrule any maintainers.
> 
> As a resolution to the specific issue at hand, I think I'd find this
> acceptable.  However, it feels like a more disruptive change than just
> flipping the Depends in question to Recommends, so I'm not immediately
> convinced it's a *better* choice.
> 
Core to the issue here is that the n-m Depends gets forced even into users 
that wants the whole platform, that is, the 'gnome' package.

Not trying to influence the ctte, but just to make clear that, for some users, 
it is desirable to have the whole Gnome platform with (e.g.) wicd or even 
manual network control.

Regards

Noel Torres
er Envite


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

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Noel David Torres Taño writes ("Re: Bug#681834: network-manager, gnome, 
Recommends vs Depends"):
> Core to the issue here is that the n-m Depends gets forced even into users 
> that wants the whole platform, that is, the 'gnome' package.

Right:

  http://packages.debian.org/squeeze/gnome
Recommends: network-manager-gnome (>= 0.8) 
# no mention of gnome-core

  http://packages.debian.org/squeeze/gnome-core
# no mention of network-manager*

  http://packages.debian.org/wheezy/gnome
Depends: gnome-core (= 1:3.0+9)

  http://packages.debian.org/wheezy/gnome-core
Depends: network-manager-gnome (>= 0.9) [not kfreebsd-amd64, kfreebsd-i386]

So if you currently have `gnome' installed but have deliberately
violated the Recommends to not have n-m, you will `forcibly' gain n-m
during the upgrade.

If we change the Depends to a Recommends then this will not occur.

I have heard that there are at least some versions of some package
managers which will fail to honour the Recommends on upgrade.  Ie that
if you previously had gnome-core, but not gnome, you might end up
without network-manager.  But that's not a particularly undesirable
situation.  It certainly wouldn't cause an existing network-manager to
be removed; the only thing you miss out on is the declared increase in
`coreness', according to GNOME, of n-m.  (And perhaps those package
manager bugs have been fixed by now anyway.)

Ian.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20485.41226.67890.53...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Russ Allbery]

Ian Jackson  writes:
> Bdale Garbee writes:
>> Gergely Nagy  writes:

>>> As a user, my expectation is that if I install a *meta* package, then
>>> the whole platform will be installed, and will be kept
>>> installed. That's the main reason I install meta packages.

>> I comprehend you, but to me the difficulty is in defining what "the
>> whole platform" means and thus where the boundary should lie.  In the
>> current case, if someone says "I want Gnome", do they really expect
>> that to include network-manager to the exclusion of all other options,
>> or might they reasonably expect to be able to use wicd, or something
>> else, as an alternative?

> Quite.

> It has also been suggested that gnome-session would be a better
> package to install, but of course that excludes all of the gnome
> applications - which is probably what the user wanted in this case.

Do we know for certain that installation of network-manager excludes
alternatives?  Tollef replied to me on debian-devel wondering why people
who don't want to use network-manager just disable it, which implies that
there's some means to turn it off while it's still installed.  (I don't
think I ever investigated that.)

I'm not sure how significant that is to the decision, but it sounded like
people are assuming that having network-manager installed excludes use of
wicd or something else, so I want to be sure people aren't making
decisions based on false premises.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874np6b8v4@windlord.stanford.edu

Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib

[Russ Allbery]

Hello all,

Could someone who has the time and the tools available do a check on all
the dependencies in main for dependencies on non-free/contrib?  This
information would be very helpful in evaluating tech-ctte bug #681419.  In
particular:

* How many total dependencies are there?  (We're only interested in
  Depends or Recommends for this purpose, not Suggests.)

* Are all of those dependencies alternative dependencies of the form:

  Depends: foo | foo-nonfree

  or are there other cases?  A list of the other cases would be very
  interesting.  (Some may just be bugs, but we may not have thought of
  some other possible pattern.)

* Are any of these dependencies versioned?  One of the things we're
  evaluating is whether it would always be possible to replace those
  dependencies with a straight dependency on foo, with foo-nonfree
  Providing foo.

It would also be quite interesting, although much harder to determine,
whether there are any scenarios where such a dependency would result in a
non-free package being installed by default.  If, for example, there's a
dependency on foo | foo-nonfree and some packages conflict with foo but
not with foo-nonfree such that a dependency resolver may pull in
foo-nonfree in preference.

Thanks!

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk6y9tq0@windlord.stanford.edu

Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib

[Niels Thykier]

On 2012-07-17 19:35, Russ Allbery wrote:
> Hello all,
> 
> [...]
> 
> It would also be quite interesting, although much harder to determine,
> whether there are any scenarios where such a dependency would result in a
> non-free package being installed by default.  If, for example, there's a
> dependency on foo | foo-nonfree and some packages conflict with foo but
> not with foo-nonfree such that a dependency resolver may pull in
> foo-nonfree in preference.
> 
> Thanks!
> 


Hi,

I suspect installability checking of all packages should find them if
they are there.  One run with non-free+contrib and one without - the
"newly" uninstallable between the two runs should be set you are looking
for.  It does not catch issues like "foo-nonfree | foo", but they would
be caught by your other query.

~Niels


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5005a8eb.6020...@thykier.net

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Russ Allbery writes ("Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> Do we know for certain that installation of network-manager excludes
> alternatives?  Tollef replied to me on debian-devel wondering why people
> who don't want to use network-manager just disable it, which implies that
> there's some means to turn it off while it's still installed.  (I don't
> think I ever investigated that.)

I don't know that we have investigated that.  But I do know that
having it install n-m might be a problem even if you can disable n-m
afterwards.  For example, n-m might break your network on
installation.

> I'm not sure how significant that is to the decision, but it sounded like
> people are assuming that having network-manager installed excludes use of
> wicd or something else, so I want to be sure people aren't making
> decisions based on false premises.

Also ISTR reading some assertions in the discussion that people who
had previously installed n-m, found it troublesome and disabled it,
had it reenabled somehow.  Not installing something is generally a
more reliable approach than asking people to fiddle with its config.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20485.43670.488179.65...@chiark.greenend.org.uk

Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib

[Ian Jackson]

Niels Thykier writes ("Re: tech-ctte help needed: main dependencies on 
non-free/contrib"):
> I suspect installability checking of all packages should find them if
> they are there.  One run with non-free+contrib and one without - the
> "newly" uninstallable between the two runs should be set you are looking
> for.  It does not catch issues like "foo-nonfree | foo", but they would
> be caught by your other query.

Unless all the package managers always prefer to avoid installing from
non-free unless there is no other way to satisfy the user's request,
this is not a sufficient test.

In practice I think if we had installability bugs of the form you
suggest, in testing, people would notice.  Since those packages would
not be installable in testing at all.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20485.43851.604329.604...@chiark.greenend.org.uk

Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib

[Jakub Wilk]

* Niels Thykier , 2012-07-17, 20:03:
It would also be quite interesting, although much harder to determine, 
whether there are any scenarios where such a dependency would result 
in a non-free package being installed by default. If, for example, 
there's a dependency on foo | foo-nonfree and some packages conflict 
with foo but not with foo-nonfree such that a dependency resolver may 
pull in foo-nonfree in preference.

[...]
I suspect installability checking of all packages should find them if 
they are there.  One run with non-free+contrib and one without - the 
"newly" uninstallable between the two runs should be set you are 
looking for.


I played with dose-debcheck a bit. It turns out that (at least for i386) 
every currently uninstallable package in main is also uninstallable 
within main+contrib+non-free.


It does not catch issues like "foo-nonfree | foo", but they would be 
caught by your other query.


That's right.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120717181448.ga6...@jwilk.net

Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib

[Eugene V. Lyubimkin]

Hi,

On 2012-07-17 10:35, Russ Allbery wrote:
> Could someone who has the time and the tools available do a check on all
> the dependencies in main for dependencies on non-free/contrib?  This
> information would be very helpful in evaluating tech-ctte bug #681419.  In
> particular: [...]

I wrote a small program to list them, please find the (hopefully
awk'able and hopefully correct) output in attachment.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
avahi-ui-utils: Recommends: 'vnc-viewer' [choice 3: tightvnc-java from contrib]
avahi-ui-utils: Recommends: 'vnc-viewer' [choice 4: vnc-java from contrib]
capi4hylafax: Recommends: 'isdnactivecards' [choice 1: isdnactivecards from 
contrib]
cl-sql: Recommends: 'cl-sql-backend' [choice 8: cl-sql-oracle from contrib]
cl-sql-uffi: Recommends: 'cl-sql-backend' [choice 8: cl-sql-oracle from contrib]
clam-networkeditor: Depends: 'libgl1-mesa-glx | libgl1 | fglrx-glx' [choice 3: 
fglrx-glx from non-free]
conky: Depends: 'conky-std | conky-cli | conky-all' [choice 3: conky-all from 
contrib]
deluge-common: Depends: 'geoip-database' [choice 2: geoip-database-contrib from 
contrib]
deutex: Recommends: 'doom-wad' [choice 1: doom-wad-shareware from non-free]
dsc-statistics-collector: Depends: 'geoip-database' [choice 2: 
geoip-database-contrib from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 12: 
festvox-don from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 13: 
festvox-en1 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 14: 
festvox-us1 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 15: 
festvox-us2 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 16: 
festvox-us3 from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 17: 
festvox-rablpc16k from contrib]
festival: Recommends: 'festvox-kallpc16k | festival-voice' [choice 18: 
festvox-rablpc8k from contrib]
freeciv-client-sdl: Depends: 'fonts-ipafont-gothic | fonts-japanese-gothic | 
ttf-sazanami-gothic' [choice 5: fonts-ipafont-nonfree-jisx0208 from non-free]
fuse-emulator-common: Depends: 'opense-basic | spectrum-roms' [choice 2: 
spectrum-roms from non-free]
gdm3: Depends: 'gnome-session | x-session-manager | x-window-manager | 
x-terminal-emulator' [choice 54: amiwm from non-free]
gjiten: Recommends: 'fonts-ipafont-mincho | fonts-japanese-mincho' [choice 4: 
fonts-ipafont-nonfree-jisx0208 from non-free]
glchess: Depends: 'gnuchess | sjeng | crafty | phalanx | glaurung | stockfish | 
hoichess | bbchess | fruit | toga2 | fairymax' [choice 3: crafty from non-free]
globs: Depends: 'libgl1-mesa-glx | libgl1 | fglrx-glx' [choice 3: fglrx-glx 
from non-free]
gscan2pdf: Recommends: 'cuneiform' [choice 1: cuneiform from non-free]
kanatest: Recommends: 'ttf-kochi-mincho | ttf-kochi-gothic' [choice 2: 
ttf-kochi-mincho-naga10 from non-free]
kanatest: Recommends: 'ttf-kochi-mincho | ttf-kochi-gothic' [choice 4: 
ttf-kochi-gothic-naga10 from non-free]
kanjipad: Recommends: 'ttf-kochi-gothic | ttf-kochi-mincho' [choice 2: 
ttf-kochi-gothic-naga10 from non-free]
kanjipad: Recommends: 'ttf-kochi-gothic | ttf-kochi-mincho' [choice 4: 
ttf-kochi-mincho-naga10 from non-free]
kdm: Recommends: 'kde-workspace | x-session-manager | x-window-manager' [choice 
55: amiwm from non-free]
kiten: Depends: 'fonts-vlgothic | fonts-japanese-gothic' [choice 5: 
fonts-ipafont-nonfree-jisx0208 from non-free]
ldm-server: Recommends: 'gnome-session | x-session-manager | x-window-manager' 
[choice 54: amiwm from non-free]
libclam-qtmonitors1.4: Depends: 'libgl1-mesa-glx | libgl1 | fglrx-glx' [choice 
3: fglrx-glx from non-free]
libdeal.ii-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libdolfin1.0-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libelmer-dev: Depends: 'libsuitesparse-dev' [choice 2: libsuitesparse-metis-dev 
from contrib]
libgeoip1: Recommends: 'geoip-database' [choice 2: geoip-database-contrib from 
contrib]
libglw1-mesa-dev: Depends: 'lesstif2-dev | libmotif-dev' [choice 2: 
libmotif-dev from non-free]
liblpsolve55-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libpetsc3.2-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libphp-jpgraph: Depends: 'ttf-liberation | ttf-mscorefonts-installer' [choice 
3: ttf-mscorefonts-installer from contrib]
libreoffice: Recommends: 'ttf-liberation | ttf-mscorefonts-installer' [choice 
3: ttf-mscorefonts-installer from contrib]
librheolef-dev: Depends: 'libsuitesparse-dev' [choice 2: 
libsuitesparse-metis-dev from contrib]
libstarpufft-1.0: Depends: 'libstarpu-1.0' [choice 2: libstarpu-contrib-1.0 
from contrib]
libstarpumpi-1.0: Depends: 'libstarpu-1.0' [choice 2: libstarpu-contrib-1.0 
from contrib]
lts

Bug#681783: Are Recommends really important (especially for metapackages)?

[Steve Langasek]

Hi Andrei,

On Mon, Jul 16, 2012 at 05:03:54PM +0300, Andrei POPESCU wrote:
> Given the above and also the recent problems in fitting the two major 
> Desktop Environments on only one CD each it would probably help if the 
> Technical Committee would take some official position on the following:

> 1. Is running a system with Recommends turned off a supported 
> configuration?

I don't think it's really useful for the Tech Ctte to try to declare whether
or not something is a "supported" configuration.  What is supported is up to
the individual maintainers or to Debian as a whole.

It would better fit within the scope of the committee to ask whether a
particular package relationship should be a Depends or a Recommends, or what
the policy should be for use of Depends vs. Recommends generally.

I do have a definite opinion of my own on this question.  If you are
applying --no-install-recommends to your entire system, you are working
contrary to the intended purpose of Policy, which says:

  The `Recommends' field should list packages that would be found
  together with this one in all but unusual installations.

To avoid the installation of *all* recommends by default is to ignore the
purpose of recommends:  namely, to list packages that *should* be installed
by default, but that the admin *may* remove from the system /if they know
what they're doing/.  The admin who ignores all recommends and leaves them
off the system can't possibly know what they're doing; they're not making an
informed decision that the Recommends are not needed on their installation.

So an admin who has passed --no-install-recommends to apt should not be at
all surprised if some functionality they care about is missing.

> It seems quite a few Debian Developers consider this rather a supported, 
> normal configuration, and not a customized, special purpose one. 
> Apparently, as a consequence, there is a tendency of having stronger 
> than necessary package relationships.

The TC could certainly rule on specific cases of this if asked.  But the
debate about whether --no-install-recommends is sane is a very old one, and
I don't think the TC giving a position statement on this is likely to
influence those who insist on ignoring the meaning of policy.

> Based on this rationale, packages should not use Depends unless the 
> given package as provided by Debian is unusable (e.g. it would crash) 
> without the depended package. An obvious example would be an application 
> and it's libraries.

I think there is flexibility here in how the maintainer draws the line
between Depends and Recommends.  "is unusable" is not exactly the line that
Policy draws.

  The `Depends' field should be used if the depended-on package is
  required for the depending package to provide a significant
  amount of functionality.

There's a certain amount of maintainer judgement inherent in this
definition, which I think is appropriate.

> Circular Recommends (or Depends/Recommends) relationships should also be 
> avoided if technically feasible, as this renders the autoremoval feature 
> of package managers almost useless.

That would be a bug in the package manager's detection of auto-installed
packages, nothing more.

> If you agree that by disabling Recommends the system administrator 
> assumes responsibility for the lack of possibly important
> functionality that may even lead to breakage (e.g. rsyslog only 
> Recommends: logrotate), this may need a coordinated effort to 
> write/adjust some documentation (manpages of package managers, Debian 
> Reference, Developer's Reference, Release Notes and possibly others). I 
> am willing to help in this regard as much as time allows during the 
> following release cycle.

What documentation, specifically, do you see that needs adjusting here? 
Debian Policy is IMHO already quite clear on this, and all other maintainer
documentation is secondary to policy.

> 2. Are Depends appropriate for metapackages?

Given the way you've worded the question here, I think the answer is
definitely "yes".

However, I think that Recommends are *also* appropriate for metapackages.

I don't see anything in the nature of metapackages that exempts them from
the usual process of considering which of the dependencies are hard
dependencies vs. soft dependencies.  Indeed, metapackages in Ubuntu are
maintained in exactly this fashion:

$ apt-cache show ubuntu-desktop | grep Depends | wc -w
82
$ apt-cache show ubuntu-desktop | grep Recommends | wc -w
125
$

For the *specific* case of a gnome metapackage, whose purpose is to install
the gnome system as defined by upstream, I think it's reasonable for the
maintainer to choose to mark as dependencies those packages which are
considered required components of the upstream GNOME system, even when many
Debian users would prefer not to install them.

The problem as I see it is not that the metapackage is constructed wrong,
but that people have differing expectatio

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Steve Langasek]

On Tue, Jul 17, 2012 at 06:29:46PM +0100, Ian Jackson wrote:
> Noel David Torres Taño writes ("Re: Bug#681834: network-manager, gnome, 
> Recommends vs Depends"):
> > Core to the issue here is that the n-m Depends gets forced even into users 
> > that wants the whole platform, that is, the 'gnome' package.

>   http://packages.debian.org/squeeze/gnome
> Recommends: network-manager-gnome (>= 0.8) 
> # no mention of gnome-core

>   http://packages.debian.org/squeeze/gnome-core
> # no mention of network-manager*

>   http://packages.debian.org/wheezy/gnome
> Depends: gnome-core (= 1:3.0+9)

>   http://packages.debian.org/wheezy/gnome-core
> Depends: network-manager-gnome (>= 0.9) [not kfreebsd-amd64, 
> kfreebsd-i386]

> So if you currently have `gnome' installed but have deliberately
> violated the Recommends to not have n-m, you will `forcibly' gain n-m
> during the upgrade.

> If we change the Depends to a Recommends then this will not occur.

> I have heard that there are at least some versions of some package
> managers which will fail to honour the Recommends on upgrade.  Ie that
> if you previously had gnome-core, but not gnome, you might end up
> without network-manager.  But that's not a particularly undesirable
> situation.  It certainly wouldn't cause an existing network-manager to
> be removed; the only thing you miss out on is the declared increase in
> `coreness', according to GNOME, of n-m.  (And perhaps those package
> manager bugs have been fixed by now anyway.)

Ah; so in my previous message to the bug, I had overlooked that there was an
upgrade issue here.  I agree that changing the network handling on upgrade
in this way is problematic, and that additional care needs to be taken so
that users who opted out of using network-manager in squeeze can have their
choice preserved in wheezy.

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


signature.asc
Description: Digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Michael Biebl]

Am 17.07.2012 14:56, schrieb Ian Jackson:
> block 645656 by 681834
> thanks
> 
> The argument about the dependency from gnome-core to network-manager
> has now reached the TC.  This has been extensive discussed, most
> recently on debian-devel.  The most recent response from Josselin is
> here:
>   http://lists.debian.org/debian-devel/2012/07/msg00210.html
> 
> It seems to me that:
> 
>  * n-m breaks the networking of enough people that this is a
>significant problem which should be fixed.

This is pure FUD without further details. Do you have any bug numbers in
particular? I don't claim that there aren't any bugs in NM but if there
are issues, they should be fixed in NM.

>  * There is not currently another metapackage besides gnome-core that
>would pull in enough of the gnome system.

You can use gnome-session and install the additional packages you want.

Also, as an alternative if you can't use network-manager for whatever
reasons,  you can install gnome-core and disable network-manager. This
is as simple as

"update-rc.d network-manager disable"


>  * There is no good reason not to use Recommends (or indeed Suggests)
>in a metapackage.

Not true, Joss put it very well at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645656#65

Ian, you can of course dismiss all those reasons (as you did in the
past), but that doesn't mean that those reasons are not valid.
I have the impression that you are biased against NM regarding this
issue and in general.

>  * In particular, tests have shown that the remainder of gnome
>functions as expected when network-manager is not installed; the
>situation appears to be the similar to that which occurs if n-m is
>installed but the system's active network connection is not one
>made by n-m.

Those so called "tests" have been done by Adam Borowski, who is known to
hate NM, so he is not impartial on this topic.

And no, it doesn't work as expected. GNOME users expect to be able to
setup their network with a single click.
None of the alternatives has a comparable integration into GNOME as
network-manager. Not wicd, and definitely not ifupdown.

We want to provide a coherent environment where the differenct
compontents are integrated as best as possible.

As for the situation where nm is installed but doesn't manage the
network connection: This is actually extremely confusing to users as
various bug reports have shown.

> So I would propose that we:
> 

>  * Overrule the maintainer of gnome-core, requiring that the
>dependency on network-manager be changed to Recommends;

If you force us to do that against our better judgement, I'm handing in
my resignment tomorrow.



Michael





signature.asc
Description: OpenPGP digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Russ Allbery]

Michael Biebl  writes:

> Also, as an alternative if you can't use network-manager for whatever
> reasons,  you can install gnome-core and disable network-manager. This
> is as simple as

> "update-rc.d network-manager disable"

[...]

> As for the situation where nm is installed but doesn't manage the
> network connection: This is actually extremely confusing to users as
> various bug reports have shown.

Are these two points consistent?  In other words, *is* it as simple as
running:

update-rc.d network-manager disable

and installing wicd or something else, or is that configuration "extremely
confusing" to users?  Or did you mean something different by the last
paragraph?

If there's a clean way to disable network-manager, I think that's a
reasonable alternative to either creating yet another meta-package or
arguing about Depends vs. Recommends in gnome-core.  But there seems to be
a lot of debate over this point.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fw8q871e@windlord.stanford.edu

Bug#681687: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).

[Brian White]

>
> Lastly, I would like to thank Brian for his impressively 16-years long
> work on
> mime-support.  Brian, feel free to stay among the uploaders !
>

Thanks.  I wish I had the energy to make some of the much-needed changes
but I'm just not involved with the project enough these days to have a good
feel for how it should be improved.

Make it great!

  Brian
  bcwh...@pobox.com
--
*Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.*

Bug#681687: missing mime entry

[Michael Biebl]

Just some numbers I got by grepping over the archive on lintian.d.o:

# of packages shipping .desktop files with MimeType associations: 601
# of packages shipping a corresponding mime file in
/usr/lib/mime/packages: 89

If a missing mime file would mean an RC bug, this would instantly make
514 packages RC buggy.
Interestingly, the particular section in the Debian policy is a should
directive, not a must, so I don't understand the reasons for making
#658139 RC.

That said, it seems to me, Debian policy and reality have diverged so
far, that imho a reasonable action her is to update or remove the
relevant section in the Debian policy (§9.7) to actually reflect current
practice.

Creating and keeping those mime files up-to-date is probably okay if you
maintain a single package or you need some of the special features that
mime-support provides. It adds up though, if you maintain multiple
packages. As maintainers time is limited and valuable I'd rather see it
spent for really important issues and simply get the patch in [1]
applied to mime-support which auto-generates those mime entries for
legacy apps which don't yet support the xdg mime spec [2].


Michael

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779
[2] http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Sune Vuorela]

On Tuesday 17 July 2012 19:15:34 Ian Jackson wrote:
>   - Some people claim that metapackages should not use Recommends.
> I disagree.

Metapackages is *someones* *subjective* opinion what a specific set should do. 
And this subjective opinion is up to the maintainer to figure it out. Not 
anyone else. 
If you disagree with *someones* opinion, you are free to not use the 
metapackage. And it is easy. The metapackage itself does not offer any 
functionality.
 
>   - GNOME upstream have declared Network Manager to be an integral
> part of GNOME and the Debian maintainer is insisting on following
> their lead in gnome-core.  The maintainer is essentially asserting
> that the very purpose of the gnome-core metapackage is to reflect
> precisely what upstream have decreed, and that we should not
> deviate.  

And this is a perfectly fine rationale. Having a set of packages that gives 
the user exactly what upstream is providing. Wether or not we shoul *also* 
offer something else is purely up to people doing the offerings. But being 
able to give the experience that upstream offers is important. And given what 
I have seen in some gnome apps, NM is needed for that experience.

NM is also the technology that Gnome has chosen to couple tightly with the 
shell in order to provide what upstream thinks is the best possible Gnome 
experience. We should allow our people to be able to provide what upstream 
thinks is the best possible experience.

> implications; both for users upgrading from squeeze and for other
> packages which depend on gnome-core.

Also note that the coupling between gnome-shell and NM has gotten much 
stronger since squeeze, so it is not unreasonable to require it harder than in 
the squeeze days. Software evolve.
 
/Sune
 - who isn't a user of the above packages, but want to have the right to 
define what the content of the meta packages he provides should do.
-- 
Man, how to unmount the microprocessor of a pointer of a program over the 
level-8 TCP icon from Word 3.6.9?

First of all you neither must explore the case, nor should mount a space bar 
for exploring the GPU.


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

Bug#681687: missing mime entry

[Michael Biebl]

there is a small typo...

On 17.07.2012 23:45, Michael Biebl wrote:
> Just some numbers I got by grepping over the archive on lintian.d.o:
> 
> # of packages shipping .desktop files with MimeType associations: 601
^
603
> # of packages shipping a corresponding mime file in
> /usr/lib/mime/packages: 89
> 
> If a missing mime file would mean an RC bug, this would instantly make
> 514 packages RC buggy.
  ^
Just in case someone was questioning my math :-)


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



signature.asc
Description: OpenPGP digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Michael Biebl]

On 17.07.2012 22:30, Russ Allbery wrote:
> Michael Biebl  writes:
> 
>> Also, as an alternative if you can't use network-manager for whatever
>> reasons,  you can install gnome-core and disable network-manager. This
>> is as simple as
> 
>> "update-rc.d network-manager disable"
> 
> [...]
> 
>> As for the situation where nm is installed but doesn't manage the
>> network connection: This is actually extremely confusing to users as
>> various bug reports have shown.
> 
> Are these two points consistent?  In other words, *is* it as simple as
> running:
> 
> update-rc.d network-manager disable
> 
> and installing wicd or something else, or is that configuration "extremely
> confusing" to users? 

I think those points are consistent. Users which deliberatly chose to
install wicd (or use other mechanisms) will most likely know what they
are doing and that this will have effects on how their desktop
environment will behave, e.g. that they will no longer be able to
configure their network via gnome-control-center, the network indicator
in the top panel will be gone, on/offline detection no longer being
available, etc.

As for the point of non-managed devices being confusing to users, I
probably need to say a few words:
In the network-manager package we go to great lengths to be a good
citizen and respect existing configuration. That means, if the
network-manager daemon finds a configuration in /etc/network/interfaces
for a given physical device, it does not manage that device under the
assumption that the user/administrator deliberately set up /e/n/i to
have ifupdown manage this interface.
It is hard to distinguish, which entries were created manually and which
by the debian installer, though.
The d-i installer typically creates a /e/n/i configuration, so users
weren't able to manage this device with network-manager after a
successfull installation, unless they manually removed the configuration
from /e/n/i.
This was extremely confusing for less experienced users and I got
numerous bug reports over the years [1].
We thus tried a compromise, where the network-manager postinst script
automatically comments out dhcp-type connections in /e/n/i (and restores
them, in case the package is removed again,fwiw).
This is admittedly quite ugly, but ifupdown didn't provide a nicer
interface to achieve that at the time.
Andrew has signaled interest in providing a better interface for that in
ifupdown, so hopefully we can solve that in a nicer way. IIRC, the
Ubuntu graphical installer no longer creates any /e/n/i configuration at
all, to avoid this problem completely.


> If there's a clean way to disable network-manager, I think that's a
> reasonable alternative to either creating yet another meta-package or
> arguing about Depends vs. Recommends in gnome-core.  But there seems to be
> a lot of debate over this point.

Disabling network-manager via "update-rc.d network-manager disable" is a
reliable and clean way to stop network-manager from running. It won't be
magically re-enabled on upgrades or restarted, since invoke-rc.d
respects if a sysv service is disabled this way.



Michael


P.S: I apologize for the threats to leave in my last email. I know this
is not professional. This whole issue is extremely frustrating though
and I'm currently quite pissed so I reacted more emotionally, then I
should have.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606268
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#681834: network-manager, gnome, Recommends vs Depends

[Russ Allbery]

Michael Biebl  writes:
> On 17.07.2012 22:30, Russ Allbery wrote:

>> If there's a clean way to disable network-manager, I think that's a
>> reasonable alternative to either creating yet another meta-package or
>> arguing about Depends vs. Recommends in gnome-core.  But there seems to
>> be a lot of debate over this point.

> Disabling network-manager via "update-rc.d network-manager disable" is a
> reliable and clean way to stop network-manager from running. It won't be
> magically re-enabled on upgrades or restarted, since invoke-rc.d
> respects if a sysv service is disabled this way.

Do you think this would be reasonable to document somewhere, since it
keeps coming up?  I'm not sure what the best place would be, although
/usr/share/doc/gnome-core/README.Debian is at least not horrible, or
possibly in the network-manager directory (or both).

(Apologies if you've already done this.  I didn't go look.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zk6y579o@windlord.stanford.edu

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Philipp Kern]

On Tue, Jul 17, 2012 at 06:15:34PM +0100, Ian Jackson wrote:
>   - GNOME upstream have declared Network Manager to be an integral
> part of GNOME and the Debian maintainer is insisting on following
> their lead in gnome-core.  The maintainer is essentially asserting
> that the very purpose of the gnome-core metapackage is to reflect
> precisely what upstream have decreed, and that we should not
> deviate.  I disagree; I think (a) we should feel free to deviate
> from upstream if doing so is better for our users and (b) anyway
> setting one of the dependencies to Recommends is not a significant
> deviation.

I think you need to substantiate the (a). Next up will then be the removal of
pulseaudio from Depends because it handles your sound system on top of and
somewhat instead of ALSA. And of course it places itself in /etc/xdg/autostart.
And I wouldn't be surprised to see people arguing that pulseaudio is the devil
and must not be required, given that dmix allows you to use multiple audio apps
at the same time.[1]

(I don't have anything against pulseaudio, I'm just saying that I don't see you
drawing the line yet.)

Kind regards
Philipp Kern

[1] I'm aware of the flaws of dmix. But I simply don't know how pulse handles
the multiuser case nowadays, apart from freeing the sound device when it's not
in use…


signature.asc
Description: Digital signature

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Philipp Kern writes ("Re: Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> On Tue, Jul 17, 2012 at 06:15:34PM +0100, Ian Jackson wrote:
> >   - GNOME upstream have declared Network Manager to be an integral
> > part of GNOME and the Debian maintainer is insisting on following
> > their lead in gnome-core.  The maintainer is essentially asserting
> > that the very purpose of the gnome-core metapackage is to reflect
> > precisely what upstream have decreed, and that we should not
> > deviate.  I disagree; I think (a) we should feel free to deviate
> > from upstream if doing so is better for our users and (b) anyway
> > setting one of the dependencies to Recommends is not a significant
> > deviation.
> 
> I think you need to substantiate the (a).

You think I need to substantiate the proposition that we should
deviate from upstream if doing so is better for our users ?
It seems an obvious principle to me.  In some sense that's the whole
point of a distro.

>   Next up will then be the removal of pulseaudio from Depends
> because it handles your sound system on top of and somewhat instead
> of ALSA. And of course it places itself in /etc/xdg/autostart.

I don't find this slippery slope argument at all convincing.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20486.1496.12021.179...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Michael Biebl writes ("Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> We thus tried a compromise, where the network-manager postinst script
> automatically comments out dhcp-type connections in /e/n/i (and restores
> them, in case the package is removed again,fwiw).

So just to be clear: consider the case where a user has deliberately
violated the Recommends in squeeze from gnome to network-manager, and
now upgrades to wheezy.  They will get network-manager back via the
hard dependency from gnome-core.  Presumably they don't want to
deinstall `gnome', so they don't have a choice about that.

If their networking is using a dhcp entry in /etc/network/interfaces,
the result of installing n-m will be that this entry will be commented
out.  So the networking will break.  Furthermore, your proposed
workaround ...

> Disabling network-manager via "update-rc.d network-manager disable" is a
> reliable and clean way to stop network-manager from running. It won't be
> magically re-enabled on upgrades or restarted, since invoke-rc.d
> respects if a sysv service is disabled this way.

... will not put it back.  That just goes to show why installing an
undesired package and disabling it is not a particularly good way to
avoid any breakage it causes.

And that's before we even consider bugs in the maintainer scripts.

If the user's networking is using wicd then installing n-m will
probably cause both wicd and n-m to manage the same interface ?  That
won't work well - it will probably break the networking - but at least
disabling the n-m as above and restarting everything (perhaps
rebooting) ought to fix it.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20486.1985.223920.779...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Sune Vuorela writes ("Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> Metapackages is *someones* *subjective* opinion what a specific set
> should do.  And this subjective opinion is up to the maintainer to
> figure it out. Not anyone else.

I don't agree with this as a matter of principle.  I don't think
metapackages are somehow special.  The contents of important
metapackages such as the ones we're discussing here have very
wide-ranging effects.

> If you disagree with *someones* opinion, you are free to not use the 
> metapackage. And it is easy. The metapackage itself does not offer any 
> functionality.

This is not a practical approach.  Users who want to avoid n-m would
have to remove at least the gnome and gnome-core metapackages, and
presumably someone would have to make replacements for them to install
instead.

With the status quo, users who have already deliberately decided to
remove network-manager will have it reinstalled during the squeeze to
wheezy upgrade.  I don't think that's right.

> NM is also the technology that Gnome has chosen to couple tightly with the 
> shell in order to provide what upstream thinks is the best possible Gnome 
> experience. We should allow our people to be able to provide what upstream 
> thinks is the best possible experience.

No, we should provide what _we_ think is the best possible experience.
In the first instance that's the maintainer's decision.  But
maintainers sometimes get things wrong, and that's why we have the TC.

> Also note that the coupling between gnome-shell and NM has gotten
> much stronger since squeeze, so it is not unreasonable to require it
> harder than in the squeeze days. Software evolve.

Experiemnts reported on debian-devel show that this `tight coupling'
is more a matter of doctrine than an actual hard functional
dependency.

Indeed on two of our platorms network-manager isn't even supported, so
it is just left out of the gnome-core metapackage!

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20486.2407.840095.111...@chiark.greenend.org.uk

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Steve Langasek writes ("Re: Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> Ah; so in my previous message to the bug, I had overlooked that there was an
> upgrade issue here.  I agree that changing the network handling on upgrade
> in this way is problematic, and that additional care needs to be taken so
> that users who opted out of using network-manager in squeeze can have their
> choice preserved in wheezy.

Given that wheezy has frozen we need to make the minimal change to fix
this problem.  So I think the only practical way of doing this is to
change the Depends to a Recommends, in wheezy at least.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20486.2695.308249.244...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Michael Biebl writes ("Re: network-manager, gnome, Recommends vs Depends"):
> Am 17.07.2012 14:56, schrieb Ian Jackson:
> > It seems to me that:
> > 
> >  * n-m breaks the networking of enough people that this is a
> >significant problem which should be fixed.
> 
> This is pure FUD without further details. Do you have any bug numbers in
> particular? I don't claim that there aren't any bugs in NM but if there
> are issues, they should be fixed in NM.

The discussion of this has been extensive.  Also, as Adam Borowski
points out, it is perfectly possible for n-m to fail in a certain
peculiar situation but for that not to be a bug in n-m.  n-m does not
have to be all things to all people, networking wise.  It doesn't even
necessarily have to be all things to all gnome users.  The bug is in
the gnome metapackages which unconditionally pull it into all systems.

> >  * There is no good reason not to use Recommends (or indeed Suggests)
> >in a metapackage.
> 
> Not true, Joss put it very well at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645656#65
> 
> Ian, you can of course dismiss all those reasons (as you did in the
> past), but that doesn't mean that those reasons are not valid.

I don't find those reasons convincing.

> I have the impression that you are biased against NM regarding this
> issue and in general.

I'm using n-m myself on the very computer I'm now typing at, after
having switched to it from ifupdown in my previous install, and have
no regrets on that score.

Please refrain from personal attacks.

> >  * In particular, tests have shown that the remainder of gnome
> >functions as expected when network-manager is not installed; the
> >situation appears to be the similar to that which occurs if n-m is
> >installed but the system's active network connection is not one
> >made by n-m.
> 
> Those so called "tests" have been done by Adam Borowski, who is known to
> hate NM, so he is not impartial on this topic.

However, he has actually done the tests.  We should believe him unless
you can show that he has made a mistake.  Furthermore, you are coming
rather close to accusing him of dishonesty.

If you would like to do tests of your own, I'd be interested to hear
about any serious malfunctions which would be unreasonable in context
(the context being a user who has deliberately violated a Recommends
and deliberately deinstalled gnome's networking management
components).

> And no, it doesn't work as expected. GNOME users expect to be able to
> setup their network with a single click.

You are twisting my word `expected'.  What I meant was that a user who
deinstalls network-manager, deliberately violating the Recommends,
should reasonably expect that some network-related things in gnome
won't work quite right (or at all).

That, presumably, is the price they are willing to pay.  They express
that choice precisely by violating the Recommends.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20486.3309.944364.487...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Russ Allbery writes ("Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> Michael Biebl  writes:
> > Also, as an alternative if you can't use network-manager for whatever
> > reasons,  you can install gnome-core and disable network-manager. This
> > is as simple as
> 
> > "update-rc.d network-manager disable"
> 
> [...]
> 
> > As for the situation where nm is installed but doesn't manage the
> > network connection: This is actually extremely confusing to users as
> > various bug reports have shown.
> 
> Are these two points consistent?  In other words, *is* it as simple as
> running:
> 
> update-rc.d network-manager disable
> 
> and installing wicd or something else, or is that configuration "extremely
> confusing" to users?  Or did you mean something different by the last
> paragraph?

No, I think you have read Michael correctly.  The "extremely
confusing" situation you get if you disable it as suggested above is
the same "extremely confusing" situation you get if you deinstall it.

Apart from any damage done to your alternative networking arrangements
by the maintainer scripts, possible transient interruption to your
networking while you attempt to fix the configuration (hopefully not
remotely), etc.

(And it's not clear to me how the gnome programs react to n-m being
started and then stopped.  Transiently having n-m running because the
package gets installed and then disabled might mean that some of them
need to be restarted AFAICT from the reports on -devel.)

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20486.3512.491932.184...@chiark.greenend.org.uk

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Kurt Roeckx]

On Tue, Jul 17, 2012 at 10:22:39AM -0700, Russ Allbery wrote:
> 
> Do we know for certain that installation of network-manager excludes
> alternatives?  Tollef replied to me on debian-devel wondering why people
> who don't want to use network-manager just disable it, which implies that
> there's some means to turn it off while it's still installed.  (I don't
> think I ever investigated that.)

I think "disable" means you need to tell network-manager that
it's not managing that interface.  I think I at least once
saw that after I stopped it manually it was restarted automaticly
over dbus or something.

I've set things up in /etc/network/interfaces, and that seems
to be having the effect that network-manager doesn't manage
that interface.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718053139.ga16...@roeckx.be