Forgot to reply-all and include the bug address...

-------- رسالة ممرّرة --------
الموضوع: Re: Bug#775318: debian-policy: Using /srv instead of /var/lib for served user-level data
التاريخ:        Tue, 13 Jan 2015 22:21:30 -0800
مِن:    Afif Elghraoui <afif.elghra...@openmailbox.org>
إلى:    Russ Allbery <r...@debian.org>



On الثلاثاء 13 كانون الثاني 2015 20:59, Russ Allbery wrote:
Afif Elghraoui <afif.elghra...@openmailbox.org> writes:

Thanks for the clarification-- I mistakenly thought this meant that the
distribution could define its own directory structure there.
Yeah, I totally understand how you could get that impression.
Unfortunately, the FHS isn't horribly clear on who the actors are at
various points.
I got a bit confused after looking at the /srv description again because
it still seems to imply that the distribution can put things there:

...Therefore, no program should rely on a specific subdirectory
structure of /srvexisting or data necessarily being stored in /srv.
However /srvshould always exist on FHS compliant systems and *should be
used as the default location for such data*.

Distributions must take care not to remove locally placed files in these
directories without administrator permission.[20]

And the footnote reads:

[20] This is particularly important as these areas will often contain
both files initially installed by the distributor, and those added by
the administrator.

I didn't think it would say "take care not to remove locally placed
files" if the distribution shouldn't be touching that directory at
all... This seems like the kind of treatment required with /etc.
Additionally, there isn't a statement like there is for /usr/local,
where the FHS says should be "empty after main installation".

One thing that I was going to add and then forgot to is that, in most
cases, software really should make its data locations configurable.  I
would say that any package in Debian that doesn't allow you to configure
where it puts its data, at least if that data is at all large (not just
PID files and similar sorts of tiny stuff where the overhead of relocating
it isn't worth it), probably has a bug.  It may just be a wishlist bug,
and it may be an upstream bug, but it might still be worth filing it.

Particularly if the data is at all large, being able to relocate it is
important and is something that we should support.  For example, in Amazon
EC2 instances, the root file system is often quite small and can't be made
larger, but more disk space can be mounted elsewhere, so it's important to
be able to move data to other paths.

That sounds like a more appropriate solution if there's no consensus on
how to organize /srv in the first place. Would it (making data locations
configurable) be something to consider adding to the policy as a
recommendation?

Afif



Reply via email to