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
Attachment:
pgpESxmd5pl6u.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
