Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Debian Traffic #26 For 13 Mar 2001

Editor: Zack Brown

By Prashanth Mundkur

Debian Home Page | Weekly News | Social Contract | Constitution | Policy Manual | Developer's Reference | Documentation Project | debian-devel Archives

Table Of Contents

Introduction

Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

1. New and Improved dpkg-shlibdeps, but in Python

25 Feb 2001 - 27 Feb 2001 (64 posts) Archive Link: "dpkg-scanlibs"

Summary By Prashanth Mundkur

People: Wichert AkkermanJoey HessAaron Lehmann Evan ProdromouPaolo MolaroJulian GilbeyAaron Lehmann

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:

"

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.
This isn't language advocacy -- this is basic software engineering. If re-writing in Python is going to make things SOOOOOO much better that it overrides these objections, so be it. If dpkg-dev is sufficiently low priority that these things don't matter, so be it.

"

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
Wichert said that the advantage of the use of dpkg -S over egrep was "Not having to rely on the actual structure of the dpkg database. " Julian Gilbey riposted with " But if dpkg-scanlibs is going to be part of the dpkg code, then why shouldn't it, at least until dpkg -S is significantly faster?" , to which there wasn't a reply.

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

2. libc5: In or Out?

26 Feb 2001 - 1 Mar 2001 (6 posts) Archive Link: "up for adoption: libc5"

Summary By Prashanth Mundkur

People: Marcus BrinkmannMatthias BerseAdrian Bunk

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.

3. Weekly Best-Of Summary of debian-user

1 Mar 2001 - 3 Mar 2001 (16 posts) Archive Link: "Weekly debian-user FAQ"

Summary By Prashanth Mundkur

People: Yotam RubinzhaowayMarcus Brinkmann

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.

"

(ed. [] 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 :-> )

4. Mozilla 0.8 Update

1 Mar 2001 - 2 Mar 2001 (7 posts) Archive Link: "ITP: Galeon -- Mozilla-based web browser with GNOME look and feel"

Summary By Prashanth Mundkur

People: Frank Belew

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.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.