Hi Paul,
On 22/03/14 at 17:43 +0800, Paul Wise wrote:
> To the candidates,
>
> Which packages from Debian contrib/non-free do you use or have installed?
Without trying to get a cleaner sheet first, vrms says:
Firmwares, documentation (make-doc, manpages-posix{,-dev}), rar (I had
to open a RAR 3.0 archive some time ago, and forgot to remove the package),
flashplugin-nonfree, virtualbox.
I'm actually quite surprised to see virtualbox in this list. Apparently
this is because:
* Move package to contrib as virtualbox 4.2 needs a non-free compiler to
build the BIOS.
(changelog of virtualbox 4.2.10-dfsg-1)
> How do you feel about Debian's approach to non-free software laid out
> in Social Contract item 5? Is it the right approach? Should we change
> it?
I'm not a big fan of SC#5.
The Social Contract describes the general principles of Debian -- the
things that bind us together as a project.
Is our position wrt non-free software really part of the five general
principles that make us work together as a project? I don't think so.
Also, the titles of the first four items summarize quite well the content
of the items. The fifth is very different in that regard. How can one
summarize it? (Stefano used to only mention the first four items of the
SC in his Debian talks, and I've been doing the same).
Finally, the wording of SC#5 is suboptimal. For example, in "although
non-free works are not a part of Debian, we support their use", the
meaning of "support" could be clarified. Is it 'we provide technical
support' or 'we defend/endorse their use'?
I think that the best solution to the above issues would be to drop SC#5
entirely. But that's my personal opinion, and I'm looking forward to
hearing other opinions on this :-)
> How much support should Debian give for non-free packages? Should the
> bug tracker accept reports about non-free packages? Should non-free
> packages remain in the Debian archive and mirror network? Should we
> continue to provide buildds for select non-free packages? Should
> non-free packages be part of releases and or receive security support?
>
> If we were to drop non-free from debian.org, what level of separation
> between non-free.org and debian.org is appropriate? The name only?
> Completely separate infrastructure and developer set? Somewhere in
> between?
I agree with the start of SC#5. We should acknowledge that some of our
users require the use of works that do not conform to the Debian Free
Software Guidelines. I think that it is important that those users can
still use Debian without suffering too much, but at the same time, we need
to make sure that they are aware of what they are doing when they install
non-free software.
Moving non-free packages to non-free.org would be a good way to highlight
that those packages are not part of Debian.
However, I wonder if we couldn't do more in terms of notifying users that
the package they are installing is in non-free. Currently, what happens is
that you add 'non-free' in sources.list, but then you kind-of forget about
it, and packages from main, contrib and non-free are just the same from the
POV of 'apt-cache search' or 'apt-get install'. It could be interesting to
explore the idea of asking for an install-time confirmation when the user
wants to install non-free packages.
Regarding the BTS, buildds, archive, mirrors and security support, it would
probably be simpler and more efficient for everybody if the current teams
continued to provide technical support for non-free packages for some time
even if SC#5 was dropped. I hope that if they did not want to take care of
those packages anymore, they would accept help from additional team members
working specifically on those packages.
Lucas
Attachment:
signature.asc
Description: Digital signature