On Fri, 2 Oct 2009 10:47:24 +0300 Roman Kyrylych wrote:

2009/10/2 Sergej Pupykin :

...

Hi,

I want to discuss using /srv directory in packages

(For reference: http://bugs.archlinux.org/task/16410)

Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages?

IMO web apps should not even be packed as packages. It's easy to download sources from an official site and install in whatever user's webserver directory is. Yes, packaging a webapp is nice for automatic upgrading with pacman, but users can have multiple web servers with multiple vhosts in /srv, so often installing something there won't make it working anyway, and user will copy/move/symlink the app to whatever directory is right for user's webserver config scheme, which is against the idea that package files (except configs) should not be touched by user, but only by package manager.

...

Would it be good if I replace /srv/http with /var/www/<package> or something like this?

No, /var is not good either. I can think about something like /usr/share/src/<webapp>, but anyway that does not make much sense, comparing to just installing the sources manually. :-/

well it would at least give you the advantage of easier seeing if there are updates, updating, getting a list of installed webapps etc. I'm fine with packaged webapps where the webapps are installed in a dir which users are supposed to symlink to. so that it's still up to the user, but they get the advantages listed above. anything more then that gets icky: webapps come with config files, default sql data, upon upgrade you usually need to do several steps such as running a bunch of sql queries etc. stuff that should probably not be done automatically. Dieter

Roman Kyrylych a écrit :

2009/10/2 Sergej Pupykin :

...

Hi,

I want to discuss using /srv directory in packages

(For reference: http://bugs.archlinux.org/task/16410)

Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages?

IMO web apps should not even be packed as packages. It's easy to download sources from an official site and install in whatever user's webserver directory is.

I perfectly concur with this.

Yes, packaging a webapp is nice for automatic upgrading with pacman, but users can have multiple web servers with multiple vhosts in /srv, so often installing something there won't make it working anyway, and user will copy/move/symlink the app to whatever directory is right for user's webserver config scheme, which is against the idea that package files (except configs) should not be touched by user, but only by package manager.

Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download. BTW, I just saw that nginx also does this: pacman -Qo /srv/http/nginx/50x.html /srv/http/nginx/50x.html is owned by nginx 0.7.62-1 In this case, this is not a webapp, but a web server. Still, this should go to /usr/share/nginx/ instead. Apache does it like this.

On Friday 02 October 2009 04:13:13 am Dieter Plaetinck wrote:

...

Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download.

this is one of the reasons why many webapps suck. they add bloat such as package/software management features. imho it's not the task of the webapp to do this. and i hate configuring every webapp to do it.

Dieter

+1 Even larger web apps with tight mysql dependencies, etc. are simple enough to install and usually come with good config scripts (Gallery2, eGroupWare, etc.). With web servers in many different locations for people that move to Arch, I think packaged web apps that try for a default "Arch" config could potentially cause more user headaches than they cure. SuSE and others have tried packaging web apps with limited success. The two exceptions to that are generally phpadministrator and phpmyadmin which I have seen successfully packaged by several distros. Just food for thought. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On Sunday 04 October 2009 04:42:19 am Xavier wrote:

On Sun, Oct 4, 2009 at 10:36 AM, David C. Rankin

wrote:

...

On Friday 02 October 2009 04:13:13 am Dieter Plaetinck wrote:

...

...

Also, major php applications usually automatically notify the admin when there is an update. Drupal does it, and phpmyadmin probably too. So there is really *no need* to package them. Whatever I put under /srv/http comes from an upstream download.

this is one of the reasons why many webapps suck. they add bloat such as package/software management features. imho it's not the task of the webapp to do this. and i hate configuring every webapp to do it.

Dieter

+1

Even larger web apps with tight mysql dependencies, etc. are simple enough to install and usually come with good config scripts (Gallery2, eGroupWare, etc.). With web servers in many different locations for people that move to Arch, I think packaged web apps that try for a default "Arch" config could potentially cause more user headaches than they cure. SuSE and others have tried packaging web apps with limited success. The two exceptions to that are generally phpadministrator and phpmyadmin which I have seen successfully packaged by several distros.

Dieter was saying it would be better to manage webapps with the package manager. You are apparently saying the opposite. So why +1 ?

Blame it on the flu, I was saying there is no need to package web apps as the only install configuration needed is to untar and uncompress them to your chosen directory and then run their configure script to setup and/or configure the database backend and then to configure the webserver if you installed outside of the document root. I think it would require way more code than necessary if the packager was also going to try and manage all of that to accommodate installs in standard and non standard locations. Don't get me wrong, I'm all for automated install scripts as long as the installer doesn't introduce more bugs along the way. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

At Fri, 02 Oct 2009 10:10:56 +0200, RedShift wrote:

If packages start putting stuff in /srv as well, where are we supposed to put OUR data? You don't want to put your data where packages put data as well.

Why not? If you download for example dokuwiki you put your pages into ./data directory inside dokuwiki one by default. What difference is installed by pacman or by yourself? (Of course you can change data files placement) The same can be applied to mediawiki and some other packages.

...

I would say, use /usr/share/www/ (or similar) for static/php files, and provide proper configuration files that set the correct Alias and Directory directives for popular servers like apache and lighttpd. Users can then use Include directives (in case of apache) to load those confighuration files and enable the web app.

It is good idea, but it needs patching for most of webapps because of webapps configs should be in /etc and user data - in /var by default.

...

Patching them is overkill, it would be an example of the unnecessary patching we do not want in Arch. I would keep them self-contained, no matter which solution will be used in the end. I wouldn't even have such a big problem with having configuration in /usr/share/www/phpmyadmin/config.inc.php or so.

...

In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only. It is not problem for user, but as I understand it should not be modificable files in /usr/share/

I put new phpmyadmin into community-testing To use it you should: - add FollowSymlinks options - append directories to php.ini open_basedir = /usr/share/webapps/:/etc/webapps - change web-alias to /usr/share/webapps/phpMyAdmin What do you think about this solution? (I hope all webapps can be adjusted with symlinking)

...

Ugh, I forgot the open_basedir problem. I'll look at what you did and will comment on it later. Generally I don't like having FollowSymlinks enabled.

open_basedir can be adjusted one time if we use common dirs for all webapps (/etc/webapps and /usr/share/webapps) I think symlink is the single way to keep proper directory structure. I check debian as reference - it does so.

Am Freitag 02 Oktober 2009 16:51:55 schrieb Roman Kyrylych:

Safe Mode (which includes open_basedir) is deprecated in PHP 5.3, and will be removed in 6.0.0.

No, safe_mode and open_basedir are different features and only safe_mode is deprecated. The usage of open_basedir is recommend. -- Pierre Schmitz, http://users.archlinux.de/~pierre

On Fri, Oct 2, 2009 at 13:23, Thomas Bächler wrote:

Sergej Pupykin schrieb:

...

 >> Patching them is overkill, it would be an example of the unnecessary patching we do not want in  >> Arch. I would keep them self-contained, no matter which solution will be used in the end. I  >> wouldn't even have such a big problem with having configuration in  >> /usr/share/www/phpmyadmin/config.inc.php or so.

...

...

...

In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only.

It is not problem for user, but as I understand it should not be modificable files in /usr/share/

There are many "should"s here:

- You should not unnecessarily patch applications. - You should not fill /srv or /home with pacman data - You should not put user-modifiable files in /usr/share

The last "should" is IMO the weakest of all. You can easily avoid violating the first two though. I would say this is the best solution, but it would be great to have some more opinions from other devs and TUs here, maybe even some from our overlord.

Modifiable files are not allowed in /usr/share according to FHS. But we have /opt which is intended for self-containing apps which is exactly what webapps are. -- Roman Kyrylych (Роман Кирилич)