Re: Bug#681419: Alternative dependencies on non-free packages in main
On Tue, Jul 17, 2012 at 12:22:13PM +0100, Ian Jackson wrote:
> 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.
Indeed.
> > > 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.
Indeed. EXCEPT Provides is not versioned. And even if it where the
main package might require a certain version of the non-free package
for it to be an alternative to the free one. That can't be mapped with
a versioned provides.
So to preserve the expressiveness we have now you would indeed need some
Do-Some-Weird-Thing: bar.Recommends =~ s/bar/bar | bar-nonfree/
which I hope nobody will ever implement.
> > > - 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.
I think you misunderstood.
If you have non-free enabled then packages from non-free are known and
known to be non-free accodring to the packages section.
The problem arises when you don't have non-free enabled. Then a
dependency on non-free looks just like any dependency on a
non-existant package. How should the UI decide which packages are
simply non-existant and which are non-free and need to be hidden?
> > 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.
But to respond to your point:
> 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.
With non-free enabled the UI could handle non-free packages
differently based on the section being non-free/*. I agree that it
probably is a good idea to have the UI search for solutions that don't
add non-free packages to the system. That is a matter of scoring and
shouldn't be too hard to do.
But I've thought of another thing that might be usefull. Non-free has
all kinds of software in it with different licensing terms. Which
basically means to do the right thing you have to read the licensing
for each to see weather you can agree with it or not.
We already have tools to present the user with bugreports, the NEWS
file and Changelog before installing a package with apt(itude). Why
not add another tool (apt-list-non-free?) that displays the copyright
file for any new non-free package and asks the user if that is
acceptable.
MfG
Goswin
Reply to: