Re: Bug#353277: ndiswrapper in main
On 3/8/06, Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> > On 3/7/06, Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> > > In our opinion the relevant principle is that:
> > >
> > > (i) If the user or administrator who is in charge of the Debian
> > > installation would have to adopt non-free software X to make
> > > sensible use of free software Y, then Y goes in contrib.
> >
> > Existing policy says something similar for free software X which
> > has not been packaged in main, for whatever reason.
>
> Are you saying wine should be in contrib ? No-one seemed to be
> arguing that it should be until we had this conversation ...
I'm not sure whether it should be there or not.
It seems to me that reasonable readings of section 2.2.1 of
current policy would suggest that WINE belongs in Contrib, and
that reasonable readings of this same policy would suggest that
WINE belongs in Main.
Personally, I'm ambivalent about the subject. I believe that the
typical user of WINE will already have contrib in /etc/apt/sources.list,
and I see no problems with putting WINE in contrib beyond the
usual "it's a change" issues.
For that matter, last time I looked at WINE, you had to edit
/etc/wine.conf (or .winerc) before it could be used. This
suggests to me that the wine development folks would look
poorly on the idea that we might want to have debian
packages which provide tools for use inside the wine
environment. Of course, that could change in the future, but
I'm not sure it's a good idea to make packaging decisions on
what could happen in the future while ignoring the present
state of affairs.
But just as I see no problem with moving WINE to config, and
I see advantages to that, I also see no immediate problems
with leaving WINE in main.
> > For example, some people might think that early versions of
> > PINE are free, but Debian has declined to package them.
> > Despite the text of the license, there is a threat of harassment
> > by the University of Washington, and I think we have a fairly
> > strong consensus that supporting PINE just isn't worth the
> > bother.
>
> Err, probably this just means that no-one can be bothered to be the
> maintainer ?
That, too.
> > We can have other reasons for not including free software in
> > Main. I believe packages belong in Contrib if they rely on the
> > installation of software we're not likely to package.
>
> You have to say something more subtle if you want to leave wine in
> main. It seems that our current policy depends on whether the
> non-packaged software is not packaged because of its legal or
> political status, or for some technical reason (eg, consider the free
> Windows accounting suite someone mentioned).
That may indeed be our actual policy.
However, these issues don't seem to be spelled out very clearly
in the policy manual. And if there's a significant gray area where
it's package maintainer's discretion, then that should be spelled
out as well.
Thanks,
--
Raul
Reply to: