Item8301: Splitting file locations for FHS compliance in Debian packages

This topic is about spreading the Foswiki install across FHS-compliant directories, the pros and cons, and finding some concensus on it.

What the FHS has to say about the different appropriate directories

/usr/share : Architecture-independent data

...

Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose.

/usr/local : Local hierarchy

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.

/usr/local/share

The requirements for the contents of this directory are the same as /usr/share.

/var/lib : Variable state information

This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation.

State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data.

/var/log : Log files and directories

This directory contains miscellaneous log files. Most logs must be written to this directory or an appropriate subdirectory.

Cons

• Existing installed base and complexity of supporting move
• Compatibility with Foswiki documentation that assumes a root directory with everything underneath
• Less surprising to existing Foswiki and tmwiki users
• Frequent bug reports by Debian users when splits were made in twiki .deb
• Confusion among Debian developers whether to follow FHS policy for webapps. Webapp policy is non-existant - there was an initial draft years ago that has not been touched beyond that first draft
• the configure web installer makes assumptions about the layout of foswiki, and there are a number of corners where is is known to fall over itself (and presumably unknown ones)

Pros

• More likely to get into FHS compliant distributions like Debian
  • FHS is extremely vague wrt webapps and is not applied in any consistent way - SD
• Less surprising to Debian users installing Foswiki for the first time
  • this is disputable, my experience has been that Debian users are not thrilled about webapps being split in the way that the twiki package was - SD
• Layout in recent use by some other large packaged webapps: Trac and RT
  • and one that is constantly changing - thus producing MORE confusion - SD
• Backups need only be of /var, and can exclude the packaged files in /usr
  • Foswiki backups do need to be of the perl libs too - else you're hoping that a new install looks similar to an old one - SD
• /usr can be taken read-only to reduce attack vectors on servers
  • ok, so we can't put the bin dir there - or anything else that a configure web installed extension might contain - SD
• /usr can be shared between jails and VMs
• On systems with multiple filesystems, disk full points more directly to a problem
  • /usr full - too many packages installed
  • /var/log full - too much traffic for logrotation schedule
  • /var/lib full - too many wiki pages and attachments
  • /tmp full or read only - causes rcs to fall over and make strange noises

-- DrakeDiedrich - 07 Oct 2009

I've added some inline comments to things that I don't agree are agreeable. (I'd like to move them to the Con's, but it'd probly be more reasonable to move them to 'disputed'.

Clearly, I consider claiming the FHS is applicable or beneficial to foswiki's debian package as a bad idea. Thats where the twiki package started, and at every turn, undoing that has resulted in more positive reactions from users of those packages. I also don't agree that this interpretation of the FHS is the only way forward, nor that its the only way that the debian project will accept foswiki.

even so - after thinking about this for a little longer - I have to come back to the old mantra:

• What, if anything is this attempting to solve. Its pretty clear from the experience of the twiki package (while in debian) that the FHS and the debian maintainers guide are not locked down fixed artifacts, and its also quite well known that for an application like foswiki that its application is malleable - to the benefit of users.

-- SvenDowideit - 08 Oct 2009

I've never been comfortable with the configure installs. They've always struck me as quite dangerous, and one of the reasons I put software into packages in signed archives is to avoid that vulnerability.

There are generally three reasons I install packages - to get changes or to deploy new hosts running with the old content. Occasionally an install is to fix damage. Having the same files in both packages and as unmanaged files on disk is a race condition and leads to unreproducible installs. Neither use case for packages is aided by putting the packaged files into a backup of local content.

-- DrakeDiedrich - 09 Oct 2009

I agree, however, there are quite a number of users of the twiki&foswiki debian packages that don't agree. And so, IMO the debs should try to support them. If we were only building packages for ourselves, then its fine to ignore other use cases - but those in the foswiki svn and in debian should cover more.

-- SvenDowideit - 09 Oct 2009

Commenting is disabled while not logged in