On Sun, 15 May 2011 18:03:06 +0200, Lennart Poettering <[email protected]> wrote: >> > Uh. I think /var is very much the right place for MySQL server data and >> > other non-user-specific dynamic data. >> >> What do you mean by non-user-specific data? > > Data not related directly to a specific Unix user.
Don't agree with that,... as it would basically mean that /srv is useless. IMHO, the separatation of having /var for "internal state data", temporary stuff, and dynamically generated stuff,... and /srv for "actual working data" is a much better separation and usage of the two. >> Any e.g dynamic indices (which can be easily rebuilt) should go to >> /var. > > Stay away from /srv please. That's admin territory, the system should > not muck around with that. a) This means that nobody uses it. b) It's not that system really mucks around with it,... what you refer to (e.g. when a DBMS would place its files into /srv) is just a convenience step of automatically doing what's actually the sysadmin's task (generating the database cluster, to use postgresql's terminology). Ideally those packages would just ask during their installation wheter (and how many, and which) e.g. database clusters should be created, suggesting the user with a recommended location. Let's use the postgres+debian example: Debconf would then ask the admin: "should I automatically generate a db cluster?" yes/no... "which name should I use" (cause there can be more of it)... And then it would suggest to create it in e.g. /srv/postgresql/version/cluster-name Thus from a conceptional point of view... there's not really anything where such packages take away power over /srv from the admin. Again,... if you define /srv to be only manually usable by admins,.. it's useless. Cheers, Chris. _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
