Debian Home Page (http://www.debian.org) | Weekly News (http://www.debian.org/News/weekly/) | Social Contract (http://www.debian.org/social_contract) | Constitution (http://www.debian.org/devel/constitution) | Policy Manual (http://www.debian.org/doc/debian-policy/) | Developer's Reference (http://www.debian.org/doc/packaging-manuals/developers-reference/) | Documentation Project (http://www.debian.org/doc/ddp) | debian-devel Archives (http://lists.debian.org/#debian-devel)
Table Of Contents
|1.||1 Mar 2001 - 6 Mar 2001||(34 posts)||Removing Perl as an Essential Package|
|2.||2 Mar 2001 - 9 Mar 2001||(27 posts)||Smaller Packages Files|
|3.||7 Mar 2001 - 9 Mar 2001||(24 posts)||Restricting Packages From Apt Sources|
|4.||8 Mar 2001 - 10 Mar 2001||(9 posts)||Archiving Historical Bug Reports|
|5.||8 Mar 2001 - 9 Mar 2001||(22 posts)||A GPLed Censorware-capable Package and the DFSG|
Want to help write KC Debian? See the KC Authorship page (../author.html) the KC Debian homepage (index.html) , and the Thread Summary FAQ (../summaryfaq.html) . Send any questions to the KCDevel mailing list. (mailto:email@example.com)
Mailing List Stats For This Week
We looked at 423 posts in 1373K.
There were 167 different contributors. 74 posted more than once. 0 posted last week too.
The top posters of the week were:
1. Removing Perl as an Essential Package
1 Mar 2001 - 6 Mar 2001 (34 posts) Archive Link: "Perl essential ?"
Summary By Prashanth Mundkur
People: Glenn McGrath, Richard Braakman, Paolo Molaro, Wichert Akkerman,
Glenn McGrath questioned the Essential status of Perl in the Debian distribution: " From my count there are 24 essential binaries, totalling 6550kB of linux-i386 debs. Perl-base is one of them at 840kB, ~13% of total essential size. Would it be a good long term goal to remove perl from Esssential and rewrite these scripts for a posix compliant shell or in c. " He provided a list of essential binaries that depend on perl. Richard Braakman replied "The reason for perl-base being Essential is not that other Essential packages can use it. It's Essential so that packages can use it in maintainer scripts (postinst, preinst, etc)." Paolo Molaro added, " If you're really concerned about size, you should propose to rewrite all the other utilities in perl: that will save more disk-space and provide the same functionality at the same time. Read some papers about ETLinux for an example of using a scripting language in the implementations of system utilities in low disk space conditions. Search for "Perl power tools" for a pure perl implementation of most of the utilities in the essential packages:-)"
Later there was a discussion on the relative security of perl scripts and C and shell code. Ilya Martynov suggested that Perl's lack of buffer overflows and taint mode made it a more secure coding language. Wichert Akkerman responded "It's just as easy to write insecure perl scripts as it is to write insecure shell scripts. Tainting only protects you from a couple of mistakes, but not all. Secure programming is not a language feature, it is something a programmer must be aware of for every line of code he writes, and even more importantly when making the initial design. "
So far, needless to say, it seems unlikely that Perl will be replaced in Debian packaging and distribution infrastructure.
2. Smaller Packages Files
2 Mar 2001 - 9 Mar 2001 (27 posts) Archive Link: "How to make Packages file 50% smaller"
Summary By Prashanth Mundkur
People: Brian May, Joey Hess, Ola Lundqvist,
Brian May complained about the bandwidth cost of downloading large Packages files, and proposed removing the long package description field: " why not split the description into a separate file, so you only have to download it if you really want it? " There followed some discussion of the pros and cons of downloading descriptions on demand and upgrading offline. Joey Hess thought "I'd rather have a large wait at the start than turn every tool that uses extended descriptions into a crawling nighmare." Brian May countered "I would rather have a small delay whenever I look up package information, rather then pay to download large descriptions (up to once a day), which in all probability have not even changed since last time. "
Several liked the idea of using diffs. Ola Lundqvist proposed to " Use cvs/rcs or similar for the Packages (and ..-tiny) file. Apt-get (and similar) store the version of the file that they have fetched. It then fetches the Packages-diff-from-vernum file which is automaticly created by from cvs/rcs.." Brian May also pointed out "Also, separating the description might make it easier for languages other then English."
Eventually the thread petered out inconclusively.
3. Restricting Packages From Apt Sources
7 Mar 2001 - 9 Mar 2001 (24 posts) Archive Link: "Possibility of packaging JDK 1.3?"
Summary By Prashanth Mundkur
People: Bernd Eckenfels, Matt Zimmerman, Anthony Towns,
A thread on apt-getting JDK 1.3 from blackdown and its mirrors eventually turned to specifying the particular packages an apt source was ``trusted'' for. As Bernd Eckenfels put it, "It is still a security problem that you are unable to limit the pachages apt will suck from a given source. It could even happen by accident that blackdown is putting some unstable libc on their server and BANG your system is hossed." Matt Zimmerman pointed out "It should be possible to prevent this using the pinning feature of the new apt (see apt_preferences(5)). You could list each package that you wish to have retrieved from the blackdown source, and pin any other packages from that source to priority -1."
Anthony Towns later provided a preview of apt 0.5,
currently in unstable:
With apt 0.5, you can be fairly detailed about how you trust sources
(as someone said in another message) but only as long as you can rely
on their Release file being correct
When Conectiva ported apt to RPM, they also added some crypto support,
which is in the process of being extended and fiddled with (and forward
ported to apt 0.5) and should hopefully allow you to have end-to-end
security (from Debian direct to the user, rather than having to trust
the mirrors and proxies in between), as well as the fine-grained security
apt 0.5 provides.
With apt 0.5, you can be fairly detailed about how you trust sources (as someone said in another message) but only as long as you can rely on their Release file being correct
When Conectiva ported apt to RPM, they also added some crypto support, which is in the process of being extended and fiddled with (and forward ported to apt 0.5) and should hopefully allow you to have end-to-end security (from Debian direct to the user, rather than having to trust the mirrors and proxies in between), as well as the fine-grained security apt 0.5 provides." This week's Debian Weekly News (http://www.debian.org/News/weekly/2001/8/ ) has some more related information.
4. Archiving Historical Bug Reports
8 Mar 2001 - 10 Mar 2001 (9 posts) Archive Link: "Old BTS snapshot"
Summary By Zack Brown
People: Richard Braakman, Joey Hess, Wichert Akkerman, Jason Henry Parker,
Richard Braakman offered:
I still have a snapshot of the BTS web pages from July 1997. It contains many bugreports that have since expired, and it's from before the time that expired bugreports were archived.
Would anyone like to keep these records? It might be interesting to add them to the archived bugs section of the BTS, though that will require some scripting.
Joey Hess gasped in ecstatic joy, "Oh, oh. I, for one, would be very interested in doing that. Though I know nada about adminning the bts. Anyhow, I'd like to keep a copy if nothing else." Richard stuck them up at http://people.debian.org/~dark/Bugs.tgz. Joey snarfed it and replied:
So I have a script that generates .report and .status files that seem to be valid. I still need to make .log files, which will be .. interesting. Crazy, crazy format.
I also need to make it look at the existing bts, and skip bugs that are _still_ open after all these years. And make it set any remaining bugs from the old snapshot as all closed, with a note saying something like "This bug was fixed sometime between 1997 and 2000; data since 1997 was lost.". Then after some more checking they should be ready to drop into archive/ in the BTS.
Wichert Akkerman also put in, "More historic BTS data: I have a complete copy of the BTS spool from October 18, 1998. If anyone is interested I'll try uploading it to a Debian server (that's gonna be fun with a 56k modem..)" Joey replied, "That should be quite trivial to import into the archive. Just remove still-existant bugs, and mark all unclosed bugs as done.."
Elsewhere, Jason Henry Parker replied to Richard's initial archive:
Interestingly, the archive contains Neal Stephenson's bug report which he talks about in /In the Beginning was the Command Line/ (available at http://cryptonomicon.com/beginning.html).
It is bug #6518 and reports that /etc/ld.so.conf was missing /usr/X11R6/lib .
Yep, and this bug and 7100 more are now available in the BTS.
This is still under beta test; we've hacked the bug view script to look in a second directory for the old bugs. They will be merged in with the real archive when we're sure they're ok, and then they'll start appearing on the indexes too.
Of course if anyone finds any more such old web archives, I can try to import them too. It's neat to see a bug as old as #563 (submitted in 1995!), I'd like to go back even further..
5. A GPLed Censorware-capable Package and the DFSG
8 Mar 2001 - 9 Mar 2001 (22 posts) Archive Link: "FilterProxy and DFSG-compliancy?"
Summary By Prashanth Mundkur
People: Bob McElrath, David Whedon, Colin Watson,
Kenneth Vestergaard Schmidt asked about the DFSG (http://www.debian.org/social_contract#guidelines) compliance of the license of FilterProxy, a web filtering package that was licensed under the GPL but had additional unusual conditions on its usage. The license file stated "This software is in an unfortunate position in that it can be relatively easily used to restrict freedom of information. I think that freedom of information is just as important as freedom to copy software. " and listed
FilterProxy is not intended to allow you to modify content
and misrepresent it as the original. Any user of FilterProxy must first
give consent for their content to be filtered, know that their content
is being filtered, and be able to determine exactly how it was or will
I am quite serious about this. In case that wasn't clear, you may not
do the following things with FilterProxy:
FilterProxy is not intended to allow you to modify content and misrepresent it as the original. Any user of FilterProxy must first give consent for their content to be filtered, know that their content is being filtered, and be able to determine exactly how it was or will be filtered.
I am quite serious about this. In case that wasn't clear, you may not do the following things with FilterProxy:
David Whedon, while sympathetic to the views of the author of FilterProxy, thought this went against Section 6 ("No Discrimination Against Fields of Endeavor") of the DFSG (http://www.debian.org/social_contract#guidelines) : " The license must not restrict anyone from making use of the program in a specific field of endeavor. " And Colin Watson was irked by the conditions on FilterProxy: "What next? "You may not use this gcc to compile censorware programs?" "You may not compile things I disapprove of against this glibc?""
The author of the package in question, Bob McElrath, later joined in
and explained the reasons for his conditions, stressing that
essentially his primary goals was to ensure that viewers of filtered
content were aware of the filtering taking place and had consented to
it, and covering his legal bases in case the content that was filtered
was modified and distributed without permission of the
content's copyright owner.
He also added:
The "LICENSE" is properly not a part of the copyright. As it states in
the my LICENSE:
The GNU Public License does not cover usage, or content/data
generated by a program covered by it. From the GPL: "Activities
other than copying, distribution and modification are not covered by
this License; they are outside its scope."
Copying is a separate activity from use. Copying is covered by the GPL.
Usage is covered by my LICENSE.
The "LICENSE" is properly not a part of the copyright. As it states in the my LICENSE:
Sharon And Joy