Re: Draft GR for supermajority fix

2012-07-13 Thread Anthony Towns 
On Fri, Jul 13, 2012 at 12:41 PM, Ian Jackson
 wrote:
> Anthony Towns writes ("Re: Draft GR for supermajority fix"):

> How about this.  I have dropped your change to the  at the end
> of the Standard Resolution Procedure.

Looks good to me.

Cheers,
aj

-- 
Anthony Towns 


-- 
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/CAJS_LCXNTn-4LspB8NvOJV=roz9ksaq7nubvmfixs_7z5oz...@mail.gmail.com

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

2012-07-13 Thread Bdale Garbee 
Russ Allbery  writes:

> The question at issue in these bugs is whether it is permissible for
> a package in main to declare a non-default alternative dependency on
> a package in non-free.  In other words, may a package in main have a
> dependency of:
>
> Depends: foo | foo-nonfree

Yes, of course this is allowed.  The standard we expect packages in main
to uphold is that they are functional and useful without requiring any
software from outside of main.  The above construction completely
satisfies that standard. 

With respect to sequencing, my expectation is that all options in main
should be listed before any options that are not in main. 

Bdale


pgpv9xN5VQfc9.pgp
Description: PGP signature

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

2012-07-13 Thread Michael Gilbert 
On Fri, Jul 13, 2012 at 4:02 AM, Bdale Garbee wrote:
> Russ Allbery  writes:
>
>> The question at issue in these bugs is whether it is permissible for
>> a package in main to declare a non-default alternative dependency on
>> a package in non-free.  In other words, may a package in main have a
>> dependency of:
>>
>> Depends: foo | foo-nonfree
>
> Yes, of course this is allowed.  The standard we expect packages in main
> to uphold is that they are functional and useful without requiring any
> software from outside of main.  The above construction completely
> satisfies that standard.

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?

Best wishes,
Mike



-- 
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/CANTw=mpzoxkysmscnn_qf6ct2z7w6i4gqz7wx82qwp-6wfa...@mail.gmail.com

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

2012-07-13 Thread Don Armstrong 
On Thu, 12 Jul 2012, Russ Allbery wrote:
> The question at issue in these bugs is whether it is permissible for
> a package in main to declare a non-default alternative dependency on
> a package in non-free.  In other words, may a package in main have a
> dependency of:
> 
> Depends: foo | foo-nonfree

I personally believe this is acceptable, but only with the following
caveat: under no circumstances should foo-nonfree be automatically
pulled in. [That is, there cannot be a conflicts or similar
arrangement where the package resolver seeks to pull in foo-nonfree to
solve the problem.]
 
For example, if foo conflicted with baz, but foo-nonfree did not and
baz was installed, foo-nonfree could be installed in preference to foo
without the user specifically asking for foo-nonfree.


Don Armstrong

-- 
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the people
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
 -- Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p390)

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



-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713205231.ga9...@teltox.donarmstrong.com

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

2012-07-13 Thread Russ Allbery 
Don Armstrong  writes:

> I personally believe this is acceptable, but only with the following
> caveat: under no circumstances should foo-nonfree be automatically
> pulled in. [That is, there cannot be a conflicts or similar arrangement
> where the package resolver seeks to pull in foo-nonfree to solve the
> problem.]
>  
> For example, if foo conflicted with baz, but foo-nonfree did not and baz
> was installed, foo-nonfree could be installed in preference to foo
> without the user specifically asking for foo-nonfree.

It seems like it would be difficult for the person adding the alternative
dependency to know whether this is the case, and it could change later
without any changes to the package that has the dependency.  That means
that I'm not sure how I would capture the above in guidance to the
packager in a document like Debian Policy.

More broadly, if it's there as an alternative dependency, then I think
it's hard to know whether the dependency evaluation scheme might choose to
pull it in for other, less obvious reasons.  For example, the non-free
version might have fewer dependencies, or the free version may have
dependencies that have transient installability issues.  I don't see how
to guarantee the behavior that you want.

I had previously assumed that we weren't worrying too much about issues
like that because the end-user had to have explicitly enabled the non-free
repository to have any of the non-free packages become candidates, and
that (having enabled that repository) they were requesting the best
possible dependency resolution including the non-free repository.  (This
is, to a large extent, exactly the point of contention in the Policy bugs
that I'm escalating.)

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

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

2012-07-13 Thread Ian Jackson 
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.

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.

 - Change the packager UI, websites, etc. which interpret this data
   for users to not show references to non-free when they aren't
   wanted.

While I have some ideas about how to do this I think designing a
solution is not really the job of the TC.  So I guess my initial view
wearing my TC hat is this:

 This usage is currently permitted.  Policy should be clarified
 right away to make this clear.

 However, it is a defect that this causes non-free software to be
 inappropriately recommended.  (Specifically, users who ask to install
 `Debian' and do not say that they want to be offered non-free
 packages should not see them.)

 This defect should be fixed.  We invite the policy maintainers, and
 other developers, to design and implement the necessary technical
 measures and/or policy strictures.

 In the meantime a bug should remain open, initially against policy,
 to track this defect.  This bug is not release-critical for wheezy.
 We recommend to the release team that it be made a release goal for
 wheezy+1 if this is feasible.

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

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

2012-07-13 Thread Don Armstrong 
On Fri, 13 Jul 2012, Russ Allbery wrote:
> Don Armstrong  writes:
> > For example, if foo conflicted with baz, but foo-nonfree did not
> > and baz was installed, foo-nonfree could be installed in
> > preference to foo without the user specifically asking for
> > foo-nonfree.
> 
> It seems like it would be difficult for the person adding the
> alternative dependency to know whether this is the case, and it
> could change later without any changes to the package that has the
> dependency.

I believe they could know at the point they added the dependency, but
it could certainly change at some point later in time. That'd just
result in a bug when it was found.

> More broadly, if it's there as an alternative dependency, then I
> think it's hard to know whether the dependency evaluation scheme
> might choose to pull it in for other, less obvious reasons. For
> example, the non-free version might have fewer dependencies, or the
> free version may have dependencies that have transient
> installability issues. I don't see how to guarantee the behavior
> that you want.

True.
 
> I had previously assumed that we weren't worrying too much about
> issues like that because the end-user had to have explicitly enabled
> the non-free repository to have any of the non-free packages become
> candidates, and that (having enabled that repository) they were
> requesting the best possible dependency resolution including the
> non-free repository.

This disadvantage is that normally you have to install specific
packages in non-free because nothing in main will pull them in. I'm
primarily worried about someone accidentally pulling in a non-free
package which has some kind of restrictive usage license.

A possible compromise would be to only allow this kind of alternative
dependency on non-free packages which do not have usage restrictions.


Don Armstrong

-- 
I'd sign up in a hot second for any cellular company whose motto was:
"We're less horrible than a root canal with a cold chisel."
 -- Cory Doctorow

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



-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120713214648.gc9...@teltox.donarmstrong.com

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

2012-07-13 Thread Ian Jackson 
Russ Allbery writes ("Bug#681419: Alternative dependencies on non-free packages 
in main"):
> I had previously assumed that we weren't worrying too much about issues
> like that because the end-user had to have explicitly enabled the non-free
> repository to have any of the non-free packages become candidates, and
> that (having enabled that repository) they were requesting the best
> possible dependency resolution including the non-free repository.  (This
> is, to a large extent, exactly the point of contention in the Policy bugs
> that I'm escalating.)

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.

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

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

2012-07-13 Thread Russ Allbery 
Ian Jackson  writes:
> 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.

>  - Change the packager UI, websites, etc. which interpret this data
>for users to not show references to non-free when they aren't
>wanted.

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.

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

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

2012-07-13 Thread Steve Langasek 
On Fri, Jul 13, 2012 at 02:46:48PM -0700, Don Armstrong wrote:
> On Fri, 13 Jul 2012, Russ Allbery wrote:
> > Don Armstrong  writes:
> > > For example, if foo conflicted with baz, but foo-nonfree did not
> > > and baz was installed, foo-nonfree could be installed in
> > > preference to foo without the user specifically asking for
> > > foo-nonfree.
> > 
> > It seems like it would be difficult for the person adding the
> > alternative dependency to know whether this is the case, and it
> > could change later without any changes to the package that has the
> > dependency.

> I believe they could know at the point they added the dependency, but
> it could certainly change at some point later in time. That'd just
> result in a bug when it was found.

I think I'm in agreement with this position, at least until another better
argument comes along.

At minimum, I agree that it would be a serious bug if installing a package
in main ever resulted in a non-free package being installed as a dependency;
and I'm generally happy to have this implemented any which way, with the
maintainers of the related packages sorting out among them what the right
way is to fix/avoid such a bug.

> A possible compromise would be to only allow this kind of alternative
> dependency on non-free packages which do not have usage restrictions.

I don't think that's a reasonable line to draw here, since the entire point
of the exercise that if a user has already installed a piece of non-free
software that satisfies the logical dependency, they should not have to
install another free package to satisfy the annotated dependency.  This
applies regardless of what kind of non-free it is.

-- 
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#681419: Alternative dependencies on non-free packages in main

2012-07-13 Thread Bdale Garbee 
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


pgpEkLWapWVa2.pgp
Description: PGP signature