Re: RFC: New required package: libblkid1
On Thu, Mar 20, 2003 at 08:38:33AM +0100, Emile van Bergen wrote:
> Of course, a lot of things can already be moved under /var without any
> changes to the FHS. Adjtime, audio mixer settings, and whatnot.
Adjtime is explicitly called out by the FHS has living in /etc. I
agree that it doesn't have to be, and that perhaps /var/state (*not*
/var/run; the file definitely needs to be preserved across reboots) is
a better place for it. Feel free to make the case that it should be
changed in the next revision of the FHS.
> But then there are a few files that must be written to and remain intact
> as long as the system is up, and be writable *before* a networked /var
> can be mounted: ifstate, now in /etc/network. Also resolv.conf, when
> using dhcp.
>
> /run is a good place for these; it's available for writing before /var,
> and the files are generally easily re-created at boot time. Non-trivial
> persistent files will have to wait till /var is mounted, for sure.
For some systems, /etc/resolv.conf is a static configuration file.
For those systems, putting it in /run is a problem, since (at least
according to some poeple; some of the proposals are a bit confused on
this point), /run will get blown away at reboot.
But the whole point of the FHS is that programs can be compiled with
looking for files in a consistent location. So it can't be
/etc/resolv.conf on some systems, and /run/resolv.conf on other
systems. For those systems that care, you could use a symlink --- but
if the vast majority of the systems out there have either a writable
root, or a static configuration --- why does this have to be something
which Debian has a whole have to torque itself over? Those people
with wierd corner cases (embedded systems, et. al.), that want a
read-only root *AND* who are using ppp can set up their system with a
symlink to /run, or /var/run, or /tmp (assuming that /tmp is mounted
as a memory tmpfs filesystem), or whatever else is appropriate. Why
does it have to be a Debian-wide decision?
I see this read-only root question as one where a few vocal people
care about, but *not* something which is generally applicable. So I
ask again --- why should we torque the entire system just to satisfy
what might be a very tiny corner case? Let's optimize for the common
case, not for the uncommon case. People who care about read-only
roots can set up symlinks today.
> (Something entirely different then: why XML? Do you really want mount to
> contain an XML parser? It seems like tabular data more than a highly
> structured tree, so why not simply use a : or tab-separated file? Just
> a bit curious).
The original code which was contributed to me by Andreas Dilger. It
uses a hand-coded XML parser which is quite small (2.7k of text in a
shared library). In contrast, libxml2.so is 610k text, 43k data, and
3.5k BSS, which just boggles the mind. The reason why XML is useful
is because we can add additional tags describing the block devices in
the future; it's much more extensible that XML, and as long as you use
a hand-rolled parser, it doesn't cost that much more than a
tab-separated file. (How to justify the existence of libxml2.so when
you can write an awfully large number of parsers at 3-4k a piece is a
different question, and why it's so bloated in the first place is a
good thing to ask. But it shouldn't be assumed that XML automatically
equals bloat, even if there is a lot of examples of bloated
programs/libraries using XML.)
- Ted
Reply to: