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

Debian Traffic #23 For 16 Feb 2001

Editor: Zack Brown

By Prashanth Mundkur  and  Zack Brown

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

Table Of Contents


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.

Mailing List Stats For This Week

We looked at 333 posts in 1167K.

There were 145 different contributors. 57 posted more than once. 0 posted last week too.

The top posters of the week were:

1. FHS Compliance

28 Jan 2001 - 5 Feb 2001 (58 posts) Archive Link: "FHS compliance and UNIX sockets"

Summary By Prashanth Mundkur

People: Oliver ElphickAnthony TownsRichard KettlewellBrian MayTollef Fog HeenEthan BensonAdam Heath

Oliver Elphick pointed out a discrepancy between Debian packages (and probably those of almost all distributions) and the Filesystem Hierarchy Standard (FHS) in the location of temporary Unix domain sockets. Most GNOME programs, ssh-agent and the X server currently put them directly into /tmp. However, Oliver pointed out that the FHS recommends that " Programs that maintain transient UNIX-domain sockets should place them in the /var/run directory."

The FHS says about the /tmp directory that "The /tmp directory shall be made available for programs that require temporary files", and recommended that the files in this directory be deleted whenever the system is booted. On the /var/run directory, on the other hand, it says "This directory contains system information data describing the system since it was booted. Files under this directory should be cleared (removed or truncated as appropriate) at the beginning of the boot process."

Some discussion ranged over programs that needed to create per-user files. Anthony Towns pointed out the FHS proviso: "Note: programs that run as non-root users may be unable to create files under /var/run and therefore need a subdirectory owned by the appropriate user." Richard Kettlewell remarked,

I remember discussing this with the FHS maintainer; that section was intended to codify existing practices such as these:

drwxr-xr-x    2 mail     mail         1024 Jan  2 09:48 /var/run/exim/
drwxr-xr-x    2 identd   nogroup      1024 Sep  4 16:04 /var/run/identd/

...rather than to suggest a /var/run subdirectory for each login user (whatever the merits or otherwise of that idea).

Anthony (whose userid is aj) didn't like this idea, as he pointed out elsewhere: " If so, it'd have to have similar permissions to /tmp, which is probably asking for trouble. The other extreme would be having directories like /var/run/aj/, which also seems like it's asking for trouble."

When Tollef Fog Heen suggested $HOME/tmp (which he later amended to getenv("TMPDIR")) as a possible location, Brian May responded "There is no system in place to automatically delete files on $HOME/tmp, nor can you use a faster file system in its place (eg local hard-disk where /home is NFS mounted, or something like tmpfs which I saw discussed recently on the linux-kernel mailing list)." Tollef came back with "I don't think my temporary files should be deleted automagically, since I do store files in ~/tmp myself, which I'd like to remove myself as well. Having some tmp reaper do it for me is the wrong thing. Others may have different opinions, of course."

Other locations that came up for discussion included /var/tmp, and /tmp/user. Ethan Benson suggested that "i think /tmp/user should be created at boot after /tmp is wiped" , but Adam Heath recommended using a pam module to create it and then setting TMPDIR. Tollef hacked up such a module: "For interested parties, is the module - pop it into a pam source tree in the modules directory."

By the thread's conclusion though, the issue of the discrepancy with the FHS (which is still evolving) did not seem to get resolved.

2. Some Confusion Over Where To Submit Bug Reports

2 Feb 2001 - 7 Feb 2001 (20 posts) Archive Link: "Xinerama and gnome-control-center problems?"

Summary By Zack Brown

People: Peter TeichmanCarl B. Constantine

Carl B. Constantine reported a lack of response on Ximian's part to respond to a bug report for the Gnome Control Center package, and Peter Teichman of Ximian replied openly, "Our BTS fell victim to an IDE controller failure, and is now sitting as several thousand files in /lost+found. Until it comes back up, new reports are being queued (and not inserted into the database). is the contact address for issues with our Debian packages." He suggested reporting the problem to the Gnome Control Center package maintainers, but Carl replied, "I'm using a ximian package and the last time I reported a bug like that to Debian I was told to report to Ximian." He asked for suggestions on who he should really contact, and Christian Marillat suggested the upstream developer.

3. Package Dependency Problems

3 Feb 2001 - 7 Feb 2001 (7 posts) Archive Link: "Correct method for aborting package installation from maintainer scripts"

Summary By Zack Brown

People: Matt ZimmermanStephen Zander

Matt Zimmerman had been working on a package that would be incompatible with previous versions of itself. Specifically, files created by older versions would not be readable by the newer version. He wanted to have debconf issue a warning when users attempted to upgrade to the newer version, to give the user a chance to abort the upgrade. This part was not a problem, he explained, because he could simply use a Pre-Depends on debconf and a check in the preinst script.

However, Matt went on, another package, also incompatible with earlier versions of itself, depended upon the first package. In fact, the second package and the first package had to have the same version number in order to successfully work together.

Calling the first package 'X' and the second package 'Y', he asked, "how can I prevent the user from breaking their installation of Y? If X and Y are being upgraded in the same dpkg invocation, Y could be unpacked before X. Although X's preinst could abort and prevent it from being unpacked, Y would already be unpacked (and unable to configure due to a versioned dependency on X)." He replied to himself after a day of pounding on the problem, saying:

This is the only solution I've come up with so far:

Create a shared/upgrade-libfoo-to-version-blah template, include it in every package that relies on the foo library, and have them all ask the question in .config and check it in .preinst. They will all have to Pre-Depend on debconf. The installation run still breaks messily if other packages are being upgraded at the same time.

I hate it. At this point, I am considering just displaying a note advising the user to interrupt the installation themselves, as there is no good way to do it programmatically, and the user has a good chance of being able to send a keyboard interrupt before dpkg actually unpacks everything.

Elsewhere and a couple days later, Stephen Zander suggested pre-depending the second package on a particular version of the first. This, he felt, would guarantee having the first installed before the second could do anything. Matt felt this would violate policy, and quoted the relevant section:

However, when a package declaring a Pre-dependency is being unpacked the predependency can be satisfied even if the depended-on package(s) are only unpacked or half-configured, provided that they have been configured correctly at some point in the past (and not removed or partially removed since). In this case both the previously-configured and currently unpacked or half-configured versions must satisfy any version clause in the Pre-Depends field.

There was no reply and the thread ended.

4. Printing in Debian

8 Feb 2001 - 11 Feb 2001 (17 posts) Archive Link: "printtool in Debian"

Summary By Prashanth Mundkur

People: Rafael KitoverOsamu AokiGrant Taylor

Rafael Kitover presented his thoughts on a " a clean Perl or Python based printer configuration system, configurable via the web (and/or dialog, gnome, gtk, tk, take your pick). Maybe just using debconf. That goes with the magicfilter system." He vented, " The printtool Tcl code is one of the ugliest monstrosities I've ever had the displeasure of dealing with, not to mention it being Tcl."

Osamu Aoki remarked that " Except for stupid TCL gui part, I think general design of printtool and RH's master-filter are acceptable one [...] It looks like RH will move to lprngtool which is basically a cleaned-up version of printtool(tcl code) with many feature enhancements." , but complained about printer databases, "Nobody has patience and time for tedious database work..."

Grant Taylor, who maintains, jumped in vigorously at this point, modestly pointed to his database of over 700 printers, and said about printtool and master-filter "It's *really* painful for end users to install new drivers, and it's almost impossible to make full use of what driver features free software drivers do provide." He thought that Red Hat " are throwing printtool away - it's DEAD. Please do not try to keep it alive. [...] The new thing in Red Hat is LPRng/magicfilter, with Foomatic driver interfacing and a GUI called printconf or printerconf or something like that." On databases, he added "Red Hat is throwing their database away as part of the death of rhs-printfilters/printtool. For a while they planned to generate it from mine, but I think that never left the proverbial building. Someone had certainly written the code to do so, though. In the future they will be using my database, just like Mandrake, SuSE, Caldera, etc. They're using my mfomatic backend, interfaced in an interesting dynamic way with a version of magicfilter 2.0." He also provided pointers to the current state and future roadmap for foomatic, a system for using free software printer drivers with common Unix spoolers.

Osamu Aoki expressed his reasons for staying with printtool: " if we want on-the-fly GUI user interface, PRINTTOOL and LPRNGTOOL are only stand-alone functioning programs on debian archive. I think keeping them alive in good working order is valid work and I, together with Rafael, hope to do. Unfortunately, it is in hard-to-read TCL code which Rafael and I do not like but we are living with it. Of course, whenever new fully functional package which supersede PRINTTOOL/LPRNGTOOL, I will be happy to change mind. In that context, I like LPRNGTOOL and may migrate to it, but had no time to check it as of now."

Grant provided contacts to other folks working on a GUI configuration tool for printing: "the Red Hat guy doing this work is Crutcher Dunnavant <>; he's on linuxprinting.foomatic.devel. I think you should join up with Till of Mandrake and the KUPS guy; they've finally gotten the bug that it would be straightforward to make a config tool that works for all spoolers."







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.