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

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

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

Reply to: