There was some more discussion of packaging OpenOffice, last discussed in .Anthony Towns asked, So, it seems we don't have StarOffice/OpenOffice packages yet in spite of three people ITPing it... Any of you care to fix this? Adrian Bunk said he was having problems building it without JDK 1.2.2. When Anthony suggested using the version from blackdown.org to build, Stephen Zander pointed out that that Openffice would likely require the blackdown 1.2.2 Java Runtime Environment (JRE) to run, which is not DFSG free. Antti-Juhani Kaijanaho said Kaffe was too buggy and only provided JDK 1.1.

Alan Shutko and Jeffry Smith later commented that the JDK was only required for optional functionality, and that OpenOffice could be run without the JRE.

Craig Sanders requested a pipe feature for debconf, so that he could use a for loop around a script which connects to a remote machine with ssh and either makes configuration changes or runs apt-get to upgrade/install/remove packages from the system. He needed this as i've got several remote boxes which need this done to them so that i can script upgrades for important packages as security updates are released

He later elaborated what he had in mind:

one of the strengths of unix is that data & configuration details can be piped around and transformed and manipulated using the whole swag of unix text manipulation tools. plain-text configuration is a strength, not a weakness.

while some special-purpose database thingy would be good for those who like to work like that, a solution that allows generic piping of configuration data in and out of debconf would work just fine for the sysadmins out there who have years of experience in the traditional unix way of doing things. [...]

it would open up all sorts of possibilities too. e.g. copying configuration data from one machine to another could be as simple as something like:

debconf --extract postfix | ssh remote.hostname debconf --configure postfix

and if you needed to transform one particular variable to customise it for the remote machine:

debconf --extract postfix | \

        sed -e "s/localhostname/remotehostname/gi" | \

        ssh remote.hostname debconf --configure postfix

now you can wrap that in a for loop to configure many machines at once:

for i in $( cat hosts ) ; do

        debconf --extract postfix | \

                sed -e "s/localhostname/$i/gi" | \

                ssh $i debconf --configure postfix

done

this is the unix "small tools" approach to problem-solving in action. it works, and it works extremely well...it has worked extremely well for over 20 years. it's very flexible and it allows people to do common or "standard" things easily without sacrificing their ability to do unusual or oddball things that they need to do for some reason or other. it lends itself to customised automation tasks.

Joey Hess responded, Well, what you're really running into is the missing third of debconf, the flexible backend database. You _should_ be able to point all these machines as a single master debconf database, or ship a database file onto them, or accomplish this in several other ways.

Very soon thereafter, Joey Hess announced that he was working on a backend database for debconf: I've been writing a backend db for debconf, since nobody else will do it. and asked for comments on the config file format.

Sam Hartman was upset with the time taken to build packages on m68k:

Steve Langasek proposed using cross-compilers for autobuilding: all the heavy compiling work could be done on heavy-duty machines, regardless of architecture . Paul Slootman pointed out a potential problem: It's not that simple, because often, during the build of a package, an executable that was compiled just before is used in the build process, and such situations won't work.

The discussion continued in a later thread, with opinions divided on the usefulness of the idea. Scott Dier pointed out the problem of tests for executable binaries during package build times. Marcus Brinkmann recounted his experiences:

During the course of the discussion, several folks came forward to offer more machines to reduce the load on the m68k build machines. Scott Dier offered a spare box, Pieter Schoenmakers came forward with an offer of two NeXt boxes, and Alain Schroeder said he was working on getting another box.

Peter Palfrader announced after some discussion on #debian-bugs that a serious bug should not be filed against a package due to the lack of a Build-Depends, since the Policy Manual said this field may be defined; he added later that Bug #87510 was a proposal to make this field a requirement. Wichert Akkerman said that a number of packages don't have build dependencies at all (everything they need is build-essential), but Julian Gilbey pointed out elsewhere that perhaps lintian should warn if there is no Build-Depends(-Indep) line, seeing that most packages will need one (for debhelper, if nothing else).

The Standards-Version field was then discussed, with Bob Hilliard pointing out the Policy was a bit vague on what "current policy" was: Is it the version in stable, in testing, or in unstable?

Julian Gilbey eventually announced I'll post an announcement to -devel-announce when the rewritten policy is ready.