Wichert Akkerman requested comments on a replacement of dpkg-shlibdeps called dpkg-scanlibs, written in python and available at http://people.debian.org/~wakkerma/:

Besides the fact that this code is actually commented and readable, the major changes in functionality are:

• properly checks for conflicting libraries. This fixed the libc5/libc6 problems we had, as well as similar problems for all other libraries. This should also catch stupid linking problems.
• no more ldd: since we have proper logic for checking conflicting libraries we no longer need ldd to figure it out for us. This also means that things should work fine on the HURD now, as well as OpenBSD and HP-UX.
• Internally caches all its data, which should make it a lot faster if you scan more binaries in one run.
• Will try to use dlocate instead of dpkg -S for extra speedups
• Will complain if a package contains a library that is used but does not have a shlibs file for it. [...]
• Scans debian/* to hunt for package containing libraries which can be used as well. Since we don't use ldd anymore you will no longer need to set LD_LIBRARY_PATH to use those libraries.

Joey Hess alertly asked Doesn't dlotate work just like locate by caching data? If so, this could result in incorrect dependancies if two library packages contained the same file, and you had one installed yesterday when the dlotate database was updated, then switched to the other today for the package build. Masato Taruishi replied that one answer could be to compare the timestamp of /var/lib/dlocate/dlocatedb with /var/lib/dpkg/status, and use that to decide between the usage of dlocate and dpkg -S.

A lot of discussion ensued about Wichert's use of Python. Aaron Lehmann expressed his sentiments: Would that make (*shudder*) python mandatory for people who build packages? We already have one required crappy language in the distribution, and I'm not convinced that it's a good idea to add yet another.

Similarly, Evan Prodromou questioned the use of a simpering goody-two-shoes Boy Scout of programming language, and later presented his reasons:

1. Converting the scripts is simple make-work. It doesn't add features, only changes the implementation. (Adding features WHILE converting, of course, is a confounding factor that's just going to introduce more bugs.)
2. Converting the scripts is like writing them over from scratch. You get the same kind of bugginess as from a first implementation.
3. For good or ill, Perl and shell are the de facto scripting languages of Debian. Throwing another language and another interpreter into the mix -- even if it's just for developers -- seems like it should be a very conscious decision. If the point is to replace Perl and bash universally, that should be stated. If the point is to have all 3 languages be part of Debian development, that should also be stated. Implement in haste, regret in leisure.
4. Adding another language means requiring an extra piece of software (python) for Debian developers.
5. Adding another language means requiring a new language for other devscript developers, bug checkers, and the like.

Paolo Molaro got back on track and pointed out Language wars aside (a rationale for the intended switch to python would be welcome, though, if it's real), the main problem with the python replacement is speed right now. . Even without python, numbers were presented showing the slowness of dlocate and dpkg -S as compared to

       egrep <fqfilename> /var/lib/dpkg/info/*.list

Elsewhere, roughly fully half the discussion focussed on the art of indentation of Python and other program text using tabs and spaces :-)

Marcus Brinkmann rocked on his heels when he received a bug report for libc5: oh my god: somebody is still using libc5. [...] [The bug] sounds easy enough to fix, but I am not prepared to compile libc5, or do any libc5 stuff at all. [...] If anyody is interested in fixing this, feel free to adopt libc5. If not, libc5 must not be included in the next release, as it doesn't build from source (yeah, this is a chance to kill it, and all other libc5 support packages, too).

Matthias Berse panicked when he heard this please don't remove it! Many commercial programs relay on libc5 at least Maple V does IIRC. Yes I know they should have moved, but we do need libc5 support at our department and still do install new boxes who need libc5 for reasons stated above. Marcus Brinkmann responded with some options: You can fetch the file you need from an older Debian dist (potato), and keep them locally for eternity. Or you can become a Debian maintainer and maintain it. I will even sign a key for you key :)

Adrian Bunk later stepped forward to adopt the package.

Yotam Rubin proposed a method of culling the best gems from the debian-user list and forming a weekly FAQ: This is better than just looking at the archives because not all questions are answered and not all answers are accurate/complete/correct/whatever. Every two or three months we'll form a summarized version of all the previous weekly FAQs. In addition to posting the FAQ on the site we could open a new mailing list: debian-user-faq.

This idea garnered support from Zhaoway, who proposed extending the coverage: Information could be collected from not only debian-user, but every public debian lists, but info should focused on *usibility* of debian systems. [This would] distinguish it from debian-news, or kernel cousin. ;)

Yotam later provided an update: I have mailed the listmasters in request to open a new debian-user-faq list. I have also started working on the FAQ itself, which will be written in LinuxDoc. If you wish to forward me answers/questions pairs from lists other than debian-user please do so. At Peter Novodvorsky's request, Yotam adopted the use of DebianDoc instead.

Marcus Brinkmann however suggested

I think you might just collaborate with the Kernel Cousin and friends managed by Zack Brown. There is already one fro debian-hurd and I think for debian-devel there is some, too.

It's not a FAQ style, but a summary of the mailing list discussion. The people doing it already have the infrastructure and know how to organize it so that several volunteers can share the work. It's very useful to look up what the state of a discussion was, and you can check with the archive to get the details if you want to. This has advantages over a FAQ, which is probably edited more and does not reveal where to find more infos in the archive.

Following debian-user in Kernel Cousin Debian would be valuable in providing additional user-oriented information. However, following debian-devel itself is a major undertaking, with a lot of good threads being omitted every week. This Cousin could use more contributors; there's more than enough excellent material to go around :->

A Mozilla packaging update was provided by Frank Belew, explaining why version 0.8 hasn't been uploaded yet: Mozilla's tarred source from upstream contains crypto code Removing this from the build is more work than I am willing to do, since I don't think there is anyone in the world who really wants another browser with no crypto support He said this was unlike Lynx, which had crypto support (SSL) added to it as a patch, instead of being present natively in the source. He added regarding the packaging itself: YES, it is a complex packaging job, and I haven't finished with 0.8 No, I'm not just going to uupdate from the M18 packages, since I'm doing it the Right Way(tm) this time [...] So no, I'm not going to upload to main due to crypto. I'm not going to upload to non-US due to the proposal merely needing a lawyer approval. If you want anymore out of me, please, get the policy proposal aborted, or get a lawyer. I am not going to explain this again.

Some proposed uploading Mozilla to non-US. Other discussion focussed on getting Mozilla and Galeon to build; both apparently not for the faint of heart.