Re: request review of fs2ram debian/control and debian/templates
Philippe Le Brouster wrote:
> Could people on this list review the contents and give any valuable feedbacks
> regarding erros in language usage?
If it trails off half way down, that means I fell asleep.
> Source: fs2ram
> Section: admin
> Priority: optional
> Maintainer: Philippe Le Brouster <plb@nebkha.net>
> Build-Depends: debhelper (>= 7.0.50~)
> Standards-Version: 3.9.1
> DM-Upload-Allowed: yes
>
> Package: fs2ram
> Architecture: all
> Depends: ${misc:Depends}, ucf
> Description: manage post-mount/pre-unmount scripts for tmpfs across reboot
This is grammatical, but DevRef prefers synopses that fit the template
"$PKGNAME provides a/the/some $SYNOPSIS". You could fix this by
making it something like:
Description: tools to preserve tmpfs contents across reboots
(I think it's more important to summarise its purpose, rather than
talking about the scripts used to implement it.)
> fs2ram manages temporary filesystems across reboots. It is possible to
> associate a pre-unmount script to a given mountpoint. At each
> shutdown/reboot, fs2ram executes the pre-unmount script and then unmount
^s
> the corresponding filesystem. Every pre-unmount script must print a
> post-mount script on the standard output. The post-mount script is saved
> and run at boot time after the corresponding filesystem is mounted by
> fs2ram.
> .
> This package provides two pre-unmount scripts aimed at preserving
> folder structure and file permissions across reboots; this needed e.g.
^is
> for /var/cache or /var/log.
There are only two outright errors here (marked ^), and it's easy enough
to follow, but here's a rephrased version anyway:
fs2ram manages temporary file systems across reboots. Each tmpfs
mountpoint can be associated with a pre-unmount script, which is
executed by fs2ram at each shutdown/reboot before the file system is
unounted. The pre-unmount script must print a post-mount script on
standard output, which is saved and then run at boot time after fs2ram
mounts the corresponding file system.
.
This package provides two pre-unmount scripts designed to preserve
folder structure and file permissions across reboots; this is needed
to allow hierarchies such as /var/cache or /var/log to be mounted as
tmpfs.
(Probably when I look at that in the morning I'll want to get rid of all
the extra relative clauses.)
> ----------8<-----------8<----------8<----------8<----------8<----------8<---
> #
> # debian/templates
> #
>
> Template: fs2ram/main_install_type
> Type: select
> __Choices: Empty configuration, Limiting the media wear-out, Privacy
> Default: Limiting the media wear-out
> _Description: fs2ram configuration preset
Oh, now this is more non-native-speakerish.
> Please select the fs2ram configuration preset that best meets your needs.
> .
> Empty configuration:
> The configuration file will be filled with an empty template. The
> configuration
> needs to be done manually.
> Limiting the media wear-out:
I'm assuming the idea here is that it's a tmpfs setup designed
to minimise writes to SSD media. I would recommend naming
them in terms of what they do, then using the description to
explain why you'd want it.
> /var/tmp, /var/log and /var/cache will be available as RAM filesystems.
> Their contents will be preserved across reboot.
(Why would you want to preserve the contents of /var/tmp?
I've got tmpreaper installed specifically to *prevent* files
staying in /var/tmp.)
> Privacy:
> /var/tmp, /var/log and /var/cache will be available as RAM filesystems.
> Only their filesystem structures will be preserved across reboot.
Rough first draft:
Template: fs2ram/main_install_type
Type: select
__Choices: Content-preserving, Structure-preserving, Unconfigured
Default: Content-preserving
_Description: fs2ram configuration
Please select the fs2ram configuration that best meets your needs.
.
* Content-preserving: /var/tmp, /var/cache, and /var/log will be in
RAM, reducing writes to the hard drive, and fs2ram will preserve
the contents of these file systems across reboots.
* Structure-preserving: /var/tmp, /var/cache, and /var/log will be in
RAM, but fs2ram will only preserve their directory structures
across reboots, not their (potentially private) contents.
* Unconfigured: the fs2ram configuration file will be left empty and
must be filled in manually.
> Template: fs2ram/rcs_enforce_ram_configuration
> Type: boolean
> Default: true
> _Description: Make /tmp and /var/lock available as ram filesystems?
> Please choose if you want to mount ram filesystems on top of /tmp and
> /var/lock.
A ram filesystem is one of the prerequisites for installing Debian on
a dead badger - s/ram/RAM/ (but also use the name "tmpfs").
Don't choose whether you want it, choose whether it will happen.
> .
> If you don't now what it means, you can safely do this (this is now
> the default behavior for a fresh install of Debian since Wheezy).
If I do [k]now what it means, is it still safe?
"Since Wheezy" technically hasn't happened yet.
Template: fs2ram/rcs_enforce_ram_configuration
Type: boolean
Default: true
_Description: Make /tmp and /var/lock into RAM file systems?
Please choose whether /tmp and /var/lock should be converted into
tmpfs mountpoints. This is the default for fresh installs of Debian.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: