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,

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/

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, http://samfundet.no/~tfheen/debian-patches/pam_tmpdir.tgz 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.

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). debian@ximian.com 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.

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:

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.

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 www.linuxprinting.org, 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 <crutcher-at-redhat.com>; 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.