On Sat, May 08, 1999 at 02:16:43PM -0500, Manoj Srivastava wrote: > I think we have descended to a level of nit picking that is at > odds with reaching a common ground.
Then let me summarise my arugment.
Currently, packages are put into contrib under a policy that is
essentially:
* Free software goes into main, unless, in order to get that software
to work, or to compile, you need to install other software from
outside main, in which case it goes into contrib.
So packages that are free but need software that's not packaged for
Debian, that's non-free, or that's distributed in non-us rather than
main currently get lumped into contrib.
That's a perfectly consistent viewpoint, and it makes people who
install from CD happy: they don't get complaints about software that's
not installable. But it has a couple of flaws. One, notably, is that
it confuses issues of freedom with issues of American export policy.
An alternative, is a policy more like:
* Free software goes into main, unless, in order to get that software
to work, or to compile, you need to install non-free software.
That's also a fairly consistent viewpoint, and it seems to be one we'd
like to move toward considering the current moves to split non-US into
main/contrib/non-free, and to allow packages in main to depend on packages
in main or non-US/main.
I don't have any issues with any of this. I think either of these is a
completely reasonable way of breaking up the distribution.
However, I also don't think it's entirely unreasonable to take a step
back, and see what we're trying to achieve, and if there's a better way
to do so.
So.
The social contract states, under the heading "Debian will remain 100%
free software":
] We will support our users who develop and run non-free software
] on Debian, but we will never make the system depend on an item of
] non-free software.
That is, we would like to create a system that doesn't depend on an item
on non-free software. I think this is a reasonable way of explaining
what we're trying to achieve with contrib.
So what does it mean to `depend' on non-free software?
I'm going to go with the definition from the packaging manual:
] The `Depends' field should be used if the depended-on package is
] required for the depending package to provide a significant
] amount of functionality.
I'll further assume that everyone on this list is able to determine what
a `significant amount of functionality' means, and what `required for'
means. I'm at something of a lost to understand package maintainers
claiming that they can't tell what a dependency is. :-/
For the purposes of this discussion, I guess I'd like to break the
general term `dependency' down into four areas:
* debian-depends: The `Depends/Pre-Depends/Recommends' relationships.
That is, packages that have a stated dependency on some other package
and won't even install (easily) without that other package.
* local-depends: Dependencies on software that isn't packaged for
Debian. The StarOffice installers, eg, depend on a number of
tarballs being present in /tmp to be of any use. These dependencies
are not stated officially, but are nevertheless recognised by
policy in determining whether software should go in contrib.
* firmware-depends: Dependencies on firmware, including BIOS chips,
CPU designs, printer hardware, ethernet cards, etc; whether upgradable
by software or not.
* remote-depends: Dependencies on software running on a remote machine,
and accessed via Debian's standard networking capabilities.
Some examples:
* xfig.deb debian-depends on libjpegg6a
What happens when you try to use xfig without libjpegg6a?
$ sudo dpkg --force-depends --purge libjpegg6a
[...]
$ xfig
/usr/X11R6/bin/xfig: error in loading shared libraries:
libjpeg.so.6a: cannot open shared object file: No such file or
directory
* The rvplayer.deb installer local-depends on the RealVideo tarball
What happens when you try to use rvplayer without the RV tarball?
Error: cannot find rvplayer archive in /tmp/rv50_linux20.tar.gz
Visit http://www.real.com/products/player/50player/downloadrealpl...
and download the "Linux - ELF" version of Real Video Player.
Correct the above problems, and when you are done, enter 'Y'
below. Or, enter 'N' to abort the installation.
* chos.deb firmware-depends on i386
I don't, unfortunately, have a non-i386 I can conveniently test
this on. Nor do I have a BIOS-less machine I can try LILO on. *sigh*
* bitchx.deb remote-depends on an IRC server
What happens when you don't have an IRC server?
-:- Connecting to port 6667 of server irc.phrozen.org [refnum 10]
-:- Unable to connect to port 6667 of server irc.phrozen.org:
Connection refused
-:- Connecting to port 6667 of server irc.openface.ca [refnum 11]
-:- Unable to connect to port 6667 of server irc.openface.ca:
Connection refused
That is, these programs are not self-sufficient without their
dependencies.
At the moment we have the following situation:
free-software debian-depending on non-free software goes into
contrib. That's fine, it doesn't cause anyone any problems.
free-software local-depending on any other software goes into contrib.
That's fine, for non-free `other' software, and for free other
software it's a reasonable way of encouraging people to package
it too.
free-software firmware-depending on non-free `soft'-ware goes into
main, because there just isn't an alternative. There aren't any
free computers going into production yet.
free-software remote-depending on non-free software goes into main.
What we want to change is to move any free-software that `remote-depends'
(or `remote-recommends', but not `remote-suggests') on non-free software
from main to contrib.
Some further comments.
Yes, when looked at from the `dependency' angle, this results in a `double
standard'. We're still ignoring some non-free software, and allowing
software that depends on it to go into main. Perhaps one day we'll have
bios-upgrade.deb's that are maintained by the community, and perhaps
one day Open Hardware will take off, and we'll have freely upgradable CPUs.
But until then, we're just going to brush that issue under the carpet.
You will, however, note the word "still" in the above. We're *already*
ignoring both this dependency, and also the issue of remote-dependencies.
This doesn't introduce a double standard, it *weakens* an existing one.
This changes the reasons we might put software in contrib. It's no
longer reasonable to say things like `Oh, no, that's in contrib. Sure,
it's DFSG-free, but it's just not free enough.' That was never
particularly meaningful to begin with -- DFSG-free is what "free enough"
*means*. Instead, contrib is `free software that requires non-free
software for its functionality.'
And yes, it may make people feel a bit uncomfortable when we tell them
that, yeah, sure, it's free and all, but that's not good enough for
Debian. But we're not trying to make people comfortable, we're trying to
produce a free operating system, that doesn't depend on non-free software.
As an aside, one presumes that a Debian GNU/Solaris or a Debian GNU/Amiga
would be a second class citizen in the Debian family, since every piece
of software in it (more or less) depends on a piece of non-free software
-- the Solaris kernel, or Kickstart and/or Workbench at least -- that
we can't even distribute.
What's the point of all this? Manoj claims it's to "coerce" people into
writing free software. Branden and I have strongly objected to that
term, but the issue does deserve discussion. Hopefully the reader can
work out for him/herself whether this is a good or a bad thing without
needing to be lead by the nose with loaded terms.
Anyway. What are we hoping to achieve here? We're hoping to educate people
out there that some of the software they choose to use, like TiK or like
True Type fonts, are still inextricably bound to non-free software. We're
naturally hoping to avoid inconveniencing anyone, unless they make an
educated choice to *be* inconvenienced.
So, by moving software to contrib, do we achieve these goals? Yes:
people can see at a glance which software depends on non-free stuff,
and, if they're so inclined choose not to use it for that reason. If, on
the other hand, they still wish to use it, it's only negligbly harder.
Contrib CDs are usually available along with the official CDs from
vendors, and mirrors generally mirror both main and contrib. So at
worst, it's an extra $5, or an extra line in your sources.list.
On the other hand, it muddies up what's in contrib. If you don't mind
installing TiK, but you'd be loathe to install xforms, then your sources.list
will need to include main and contrib, but not non-free. But if it does,
you'll get bothered by messages about how xisp can't be installed because
libforms doesn't have an installation candidate.
This isn't good, and could do with solving. On the other hand, it could
use solving in the general case too: presuming software in contrib depending
on non-US/main software is moved into main, then we again have programs
that can't be installed because their dependencies simply can't be met.
And all of that was well and good, but what's so wrong with remote-depends
anyway? The problem is exactly the same as ordinary dependencies: you're
reliant on someone else's proprietry code to use your software. If the
server gets shutdown, or stops being maintained, your free software
becomes -- at least until someone writes a replacement -- completely
worthless. If the owner of the server starts charging money for
connection, you either pay up, or hope someone writes a replacement. If
the owner of the server decides they don't like you, you're out of
luck again.
That's why non-free servers are still `bad', in spite of free clients
being available. And as such, I don't think non-free servers and protocols
deserve the endorsement they'd obtain by allowing clients to be part
of the Debian system.
Another issue that then arises is `what's good enough for a free server?'.
For example, while lesstif exists as a replacement for motif, it's not
perfect. Similarly, the program `netcat' can serve as a replacement
server for *any* client, can't? It'll accept connections, then not doing
anything, and that's at least *something*. What it won't do is enable you
to get at a significant amount of the functionality of most programs. For
example, with irc, bitchx will simply sit there waiting for something
to happen. There's certainly some ambiguity here, but no more or less
than determining when lesstif is enough of a motif replacement for its
dependents to go into main.
OTOH, with Perl and netcat, you can write a fairly simple script to do
the other half of the conversation. At what point does "configuring a
server" become "writing a server"? Are you just configuring gcc to be
a motif replacement? Or are you writing a motif replacement? Are you
configuring netcat to act as an IRC replacement, or are you writing
an IRC replacement? Are you configuring ircd to act as an openprojects
replacement, or are you writing an openprojects replacement?
There's an issue here, but again, I don't think it's one where there's a
problem in practice. It's clear that when you're involving gcc that goes
beyond just configuring a package, and a rule like, when you're writing
the protocol steps yourself, that goes beyond just configuring a server,
isn't much harder to deal with.
Finally I've been ignoring the whole `pure' issue. I don't think that's
at all a reasonable thing to do. I believe remote-depends are exactly
as much a dependency as local-depends, and as such, I think they should
have the same consequences: removal from the official Debian GNU/Linux
distribution. I think the social contract supports that line of reasoning.
But I don't see what the point is saying "This software's free, it doesn't
depend on non-free stuff in any important manner -- but here, look at this!
This is not only free, but it depends on *less* non-free stuff than that
other stuff". Or at least that's how it seems to me. :-/
But anyway. I said when I joined this discussion that it doesn't really
matter to me. I use non-free software and contrib software and I don't
have a particular issue with that. I certainly don't have a particular
issue with using free clients that happen to talk to non-free servers. I
do think this is an appropriate distinction for Debian to draw, though,
for the reasons outlined above, but it just plain isn't going to affect
me personally in any way. So I think I'm going to more or less bow out of
the discussion. If someone else wants to take up the torch and continue
the flamewar for another week -- or hell, even write a proposal for Manoj
to formally object to -- feel very free.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``Smart, sexy, single. Pick any two (you can't have all three).''
-- RFC 1925, paraphrased: a guide to networking in the '90s
pgpBnAdWtMjPR.pgp
Description: PGP signature
