sponsor rules
>From the package names and Descriptions, I found a package today that
was something of particular interest to me; in fact, I'd been thinking about
packaging it myself, but was delighted to see that it had already been
packaged. Let's call this package 'foo'. When I tried to download and
install 'foo', I quickly discovered that its dependencies were not satisfied
by other packages in the archive, so of course it couldn't be installed
(i.e., using Debian packaging tools, without using --force). This package
is one of a group of related packages, some of which did not pass the most
basic lintian tests.
I then went and did some further investigation of 'foo'. It turned out:
-- the package and its relatives are over 1 week old, and a bug report
noting the missing dependencies was filed nearly a week ago. The fix
is not in incoming (as of the writing of this note).
-- the package was developed by someone who has applied to be a new
maintainer, but who has not gotten very far on that process yet;
in fact, the database showed that even his ID hasn't been checked yet!
-- the package (or any near relative as far as I can tell) was not ever
announced in the WNPP.
Apparently, the package was sponsored by some debian developer who didn't
have much time to make _any_ checks on it before sponsoring it.
This leads me to the question, what are the rules for sponsorship?
I couldn't find the word 'sponsor' in any of the files in either of:
--developers-reference (version 2.8.7), or
--debian-policy (version 3.5.5.0).
If there are no rules for sponsorship, and no consequences for sponsoring
blatantly buggy packages, then I guess each user simply has to develop his
own experience database wrt maintainers whose packages can be trusted [1].
But it's hard to imagine having the time, when deciding whether or not to
install a package, not just to study its Description, but also to check
the background of its developer.
This whole experience seemed like an awfully big hole in the debian
packaging/archiving policies; if I missed something, I'd very much appreciate
being corrected.
Susan Kleinmann
[1] In that case, it sure would be great if the installation tools had a
feature that supported a killfile where one could list developers whose
packages inspired a certain level of apprehension.
Reply to: