On Wed, Jun 27, 2007 at 09:48:32PM +0200, Nicolas Mailhot wrote:
Bad excuse, we ship a lot of services default-disabled, we could
ship
default-disabled srv layouts
Yes, but nuking an rpm captured rpm layout means breaking rpm.
We can provide examples and templates. Users that know better will
do
what they want as usual. No best policy is no excuse for no policy.
$ ls /srv
ftp
httpd
foo
bar
$ rm -fr /srv/*
$ for domain in $domains; do mkdir -p /srv/$domain/{ftp,httpd,foo,bar}; done
$ rpm -V vsftp httpd foo bar
missing /srv/ftp ...
missing /srv/httpd ...
...
No, not really.
A distro rpm layout is a layout that just works with distro
defaults,
which is already quite a high standard.
There is no single standard, and there is good reason for that.
> If you don't know what data will be under /srv and how the
sysadmin
> will be managing it you can' provide anything of this kind.
You can provide a default webdav/ftp/samba layout, we've done so in conf
files for years.
See, above, we don't have an rpm attribute that says "possibly ignore
the following layout" liiiike we have with %config.
> And you can't enforce a model that works for half the users
and
> not for the other half.
Again you're making it a special case when the same arguments could be
used to advocate no choices in most of the filesystem.
No, this comparision is not fair. Or give an example. The popular
modeeeels in /srv usage are really relevant and break each other.
We're not gentoo we make choices for users and then let them
amend
our choices.
Ouch. No, we're a general purpose distro with different users, we will
neither send the home user, not the professional syadmin home.
> > You can have a /srv/default and a /srv/local, or a /srv
and
> > /local/srv, or whatever but two totally different policies is just
> > shooting ourselves in the foot.
>
> /srv is already in various FHS-compliant use on thousands of
> sites. You can't touch it really. And if you were to create a
> /vendor-default-and-examples/srv then you can use /var/lib/foo as
> well.
No, /var/lib/foo is mixing local apps and content, that's the kind of
mixup that got stuff kicked from /home in the first place.
This hierarchy holds state information pertaining to an application or
the system.
> In fact many "data carrying" applications like name
servers, MTAs
> etc. use /var in the FHS, although technically they would have to move
> that content to /srv, by /srv's definition.
They should. They will someday. Or something else will deprecate /srv.
They can't. Because there are choices that you can deprive the users from.
> And in fact² in a multi-domain setup one is often forced to do
so
> to separate instances.
That only means you have several resources, and you can map them to
several domains, not that the resources names should be domain names.
No, I wrote instances vs virtual setups (although the latter got
trimmed).
--
Axel.Thimm at
ATrpms.net