In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: [rbootd directory choice] >the usual problem : you have an application and need an application home. >with ftp it's /home/ftp, for web server /var/www, and for many other stuff >it's currently /var/lib/<package> or /var/spool/<package>. > >but with slink you should use fhs, so it's ??? >/var/state/<package> /var/cache/<package> and /var/spool/<package> >are possible : > - cache for data, that can get lost and regenerated > - state for more permanent data > - spool ... something in the middle. it exists for compatibility reasons :-)
Hmm. Is the local sysadmin allowed to put random files in /var/ ? I thought you couldn't guarantee that the distribution wouldn't stomp on them... [if the local admin can't add files then the package is useless because it provides no boot images itself :->] >do not use : > /usr/local/* distributions should not touch that tree But in this case we aren't really using it; we're just saying 'if you put files in this directory then rbootd will serve them'. The policy manual explicitly says that we can create directories under /usr/local; is this advice now out of date? IMHO the right thing would be for rbootd to be able to accept more than one directory, specified in the configuration file rather than at compile time. Then we could have /var/whatever and the local sysadmin could use /usr/local/whatever. But that's not totally trivial as it requires some restructuring of the way the daemon works... Peter Maydell [I suppose I'm the upstream maintainer, BTW :-> (and the NetBSD guys are upstream of me, until I get round to submitting my patches...)] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
