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.
Ian.
Reply to: