On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
On Sunday 23 March 2008, Axel Thimm wrote:
> On Sun, Mar 23, 2008 at 06:26:35PM +0200, Ville Skyttä wrote:
> > On Friday 21 March 2008, Tom "spot" Callaway wrote:
> > > I've added another draft to the todo list:
> > > http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
> > If this passes, it needs a statement what to do with
> > already use /srv in a way that conflicts with the draft. /srv/foo is
> > typically data, potentially lots and lots of it, so auto-migrations are
> > practically out of the question and manual ones are possibly nontrivial
> > amounts of admin work. Therefore I'd suggest letting them stay as is.
> Which packages are these?
vdr (maintained by yours truly) is one. There's easily tens or hundreds of
gigabytes of DVB recordings in /srv/vdr.
> Maybe they can check whether they are being upgraded (from a
> package evr polluting /srv) or freshly installed. In the latter
> case they should behave as every other package, e.g. not assume
> anything about /srv.
I suppose that's possible (didn't think of that, thanks), but will
lead to more or less fragile config file modifications in
Why fragile? It either checks whether a previous vdr config told vdr
to put files there or looks whether /srv/vdr exists.
I'm leaning on the side of calling these modifications uglier
just leaving the data where it is in /srv
As said if the data is there leave it there. If it is a new install
then have the user decide where he needs his data being placed in. So
you'll keep legacy users happy and a clean /srv in new
installs. Wiring in /srv/vdr forever would break any site using
/srv/<domain>/<service> setups (like mine ;).
especially because there's no certainty how this issue will be
treated in the future (the draft contains things like "unclear" and
"At this time").
These attributes including the "poor wording" are just spot's POV on
the FHS' stand on /srv. In fact the /srv hierarchy has been beaten to
death in various groups, be it FHS or LSB and the outcome is always
that no standard can or should dictate what the setup should look like
as it already diverges in typical single and multiple instance setups.
IOW there will never be any further detailed specification from any
standard on how to have users treat their data layout. But maybe some
further rationale should be added to the FHS to make readers
understand why there should be no vendor given contraints on the
layout. Changes in the FHS are real slow, though (see my libexec
standardization attempts a long while back).
Axel.Thimm at ATrpms.net