On Mon, Mar 21, 2016 at 03:03:08PM +0100, Ludwig Nussel wrote:
suggest to package "web applications" to /srv/www/%name. I see two
major problems with that
1. /srv is considered admin space so packages should not mess with
it. Citing FHS¹: "... no program should rely on a specific
subdirectory structure of /srv existing or data necessarily being
stored in /srv ... Distributions must take care not to remove
locally placed files in these directories without administrator
2. For the reason that admins are expected to put files in /srv that
are not tracked by package management, /srv is a default btrfs
subvolume. That means anything installed in /srv is excluded from
the default system snapshots. Ie rollbacks of packages that
install code in /srv won't have any effect and the rpm database
would not reflect what's actually running anymore.
Therefore I'd like to propose to change the section to the
Web applications packaged in openSUSE should place their their files
in /etc, /usr, /var etc depending on type just like any other
application would do. A package must not install, remove or
otherwise modify /srv content as it's use is reserved to the admin
according to FHS¹. It's ok to allow the admin to configure the
software to use /srv of course.
Well, I strongly disagree. What you propose goes far beyond the quote
from FHS you tried to use to support your proposal.
Currently, the common practice for servers like FTP servers, TFTP
servers, HTTP servers etc. is to create a logically named subdirectory
under /srv, set its permissions as needed and point the default
configuration of the daemon to it.
Important observation: this common practice does not contradict the FHS
quote at all. However, your proposal strictly forbids it. Therefore such
rule has no support in the FHS quote.
If the proposal was accepted, packages would have to do one of
(a) not create a subdirectory under /srv and not set default
configuration to use it; all they could do would be to tell users
to create such directory themselves, set their permissions, setup
the configuration accordingly and then they could finally put
their files there
(b) not create a subdirectory but at least prepare the configuration;
it would still require users to do the job packages could (and
IMHO should) do for them; moreover, there are daemons which handle
configuration refering to non-existing paths as an error or warn
Sure, if someone installs a big public production server, this extra
work is negligible (let's forget for a moment such admin is unlikely to
use openSUSE but whatever is imposed on openSUSE is going to affect SLES
one day). But there are other use cases. Today, if I want to setup a
TFTP server in my home LAN to start an installation using PXE boot, I
just put the files into the right directory and enable the service in
xinetd.d. If your change gets through, I'll have to find out I have to
create the directory, set its permissions, edit the service config and
then enable the service.
All the time I'd keep asking two questions (if I didn't read this e-mail
which most users would not). First, why the ____ didn't the package
prepare a ready to use configuration if it would be so trivial. Second,
who is this obstruction going to help? And as a distribution user,
I wouldn't be happy about the answer "Sorry, not my call, it's just
because of one guy who misinterpreted one sentence in FHS."
So please rethink your idea. Packaged web application installing a full
directory structure with all files under /srv/www is one thing,
completely forbidding any package to install even one empty directory
under /srv is an overkill which would only make the packages less user
friendly without any benefit.
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org