[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


Reply to: