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.

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.

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.

Richard Braakman offered:

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:

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:

Joey replied:

[...]

Kenneth Vestergaard Schmidt asked about the DFSG 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 be filtered.

I am quite serious about this. In case that wasn't clear, you may not do the following things with FilterProxy:

• Remove naughty words
• Remove pornography
• Remove "harmful ideas" in any form
• Enforce access policies.

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: 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."