Re: summary of software licenses in non-free
On Sat, Jan 10, 2004 at 12:55:07PM +0100, Sven Luther wrote:
> > [For the W3C docs, for example, there is no reason except convenience
> > why they would _have_ to be served from .debian.org - could we get them
> > to host the .debs of their own documentation? ]
>
> The problem with third party servers, is for how long they will be able
> to make a commitment, and how will the end user know that this is the
> right place for searching them, and be sure he can trust a random
> apt-source he place in his list.
There's a more important reason not to split out the documents, which
is that at least when they're part of non-free, we know about the
namespace reservation. The most you start encouraging, in a big way,
the proliferation of third-party servers, you start running into the
same problems that RPM-based systems such as rpmfind have:
*) It's confusing to users; they need to find all of the
various different places where packages are kept.
*) If you have packages which have cross-dependencies across
different 3rd party servers, life gets even harder. Not only
does "what 3rd party archive do I need" become exponentially
more difficult, but potential version conflicts/dependencies
also become much more likely.
*) Once you lose control of the namespace, then life becomes
even worse. Conflicts in naming of packages between two 3rd
party servers become more likely, but even worse are conflicts
between a name which has been used for years and years by some
3rd party server (which might be moderately famous and used by
a large proportion of Debian users, Stallman's rants
irregardless), and a new Debian package.
Now, you can hand-wave these problems away as "well, these are all
non-DFSG compliant packages", so it doesn't matter. But the last
actually starts to impinge on core Debian packages. If you have a new
Debian package which conflicts with a name in a third party package,
and other packages that declare dependencies on this name, very
confusing things can happen since some packages may think that a
dependency has been satisfied, when it fact it really hasn't. This
will cause confused users, and ultimately bug reports complaining
about the problem.
(And of course, when they file bug reports on a package with a
namespace conflict, the bug report may very well go to the wrong
maintainer, depending on which package they actually have installed on
their system.)
To some extent, we have some of these problems today. People have
experimental deb archives, and there is of course the jokingly named
"debian-non-legal" archive at marillat.free.fr, and some 3rd party
debian archives already have packages with naming conflicts with
official debian packages, most notably at rarewares.hydrogenaudio.org.
And truth to tell, these problems are mostly manageable.
While these problems are relatively small at this point, if we were to
start start seeing very large numbers of 3rd party servers, the
possibilities of namespace conflicts would start to go up, and
ultimately Debian users (who like it or not, *do* use non-free
packages; the fact that we have such the non-free archive at all is a
recognition of this fact) would start to suffer. The end state would
be that Debian will no better in this regard than any of the other
RPM-based distributions using rpmfind.
Of course, it is possible to solve this problem technically; the Linux
Standard Base has one solution to the package naming problems, but it
makes the names look very ugly --- you do stuff like name packages
"lsb-adobe.com-acrobat-reader". People have laughed in derision
becomes the names seems overengineered, but trust me, it's better than
the alternative, which is lots and lots of namespace collisions.
Alternatively, if we were willing to make changes to dpkg, we could
start adding 128-bit UUID's to packages, and optionally have
dependencies that are based on the 128-bit UUID's. Ultimately, we
could transition the real "name" of the package to be the UUID, and
use the human-readable name as a user-interface crutch. This is not a
trivial change however; this would ultimately be a fundmental
architectural change to the Debian packaging system.
The bottom line is that naming is a fundamental computer science
problem, and naming is non-trivial, especially in a distributed
system. My advice? Keep everything centralized in a
debian.org-hosted non-free section; life will be much, much,
***much*** simpler.
- Ted
Reply to: