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 stu
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
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 s
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
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 w
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?
H
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
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-
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
>> d
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 co
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, ema
11 matches
Mail list logo
