-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just quoting the parts that need to be quoted ...
What about - template files that a user might customize (even if only 1% actually does it)
If the app is customizable, templates are either "data" (html with snippets of php)
(did you forget the "or" counterpart for the "either"?)
Yes. It was about configurable templates and that any app I remember Sometimes I read twice before sending to filter out lines with less rational motivation and then I forget to repair the sentences.
- a CMS that allows uploading pictures etc.
Uploadable data should reside in DB or a data dir or any other data store. In fact most apps I have seen do it this way.
Yes, and if you are lucky, they even have a data dir != the webroot ;-) (fortunately most webapps at least honor this basic rule)
I'll call this case "traditional web app". Obviously, I expect modern production ready web software to have a more suitable design. Apart from that, if something cannot be made work our way without too much trouble, we shouldn't. That's why my proposal includes a fallback location for this kind of stuff and for packagers which do not (now) have the time to convert. We can review what happens and react. If there is few stuff in /srv/{fallback} then fine. If there is most stuff in /srv/{fallback} and only select stuff installed system-style, we're not harmed at all - - but we still have stopped the confusion if it should be /srv/www/htdocs or /srv/www/something or /var/lib/stuff
- a webapp that allows to install extensions from an online repo (repo as in "write some PHP files somewhere", not as in "collection of rpms" ;-)
How should additional files in a plugin dir be affected by a proper rpm? They are not. They are not "affected" by the RPM, but they still open up an interesting question.
Let's assume the webapp itsself lives in /usr/lib/mywebapp/, comes with some plugins in /usr/lib/mywebapp/plugins/ and now someone installs another plugin from an online repo (= no rpm). Where should this plugin be stored? - /usr/lib/mywebapp/plugins/ - that means backup fun and violates the FHS (a system should work with read-only /usr)
Obviously, it needs install time rw access. I don't want to split hairs now ;-) I understand your case is "webapp admin not aware of / not in charge of underlying system". Then he doesn't update the rpm-based base app, too.
- /var/something (or /srv/something, doesn't really matter) - will probably result in a symlink hell in the first place (because you'll need a symlink for every plugin shipped in the rpm instead of one symlink for the symlink directory) and it will become even more interesting if the next version of that webapp contains additional plugins (which means you'll have to create additional symlinks on upgrade) - always assuming the package uses symlinks to handle the FHS-compliant packaging
I don't say it's impossible, but at least it makes the packaging very interesting[tm] and, main problem, possibly makes the package hard to understand for users.
The perfect solution is that the webapp supports two plugin directories (one "global" for plugins contained in the upstream tarball and installed by the rpm, and a "local" one for additional plugins that the user added somehow). Typo3 does it this way[1], but many others only allow a single plugin directory.
See above: Where it won't work, it won't work.
Yes ;-) I expected your answer, and I couldn't agree more. Nevertheless some webapps offer this option, and I'm quite sure if someone installs wordpress as rpm, we'll get a bugreport that the built-in online update fails because of missing write permissions ;-)
Wordpress should be shipped with the disable core updates plugin ;-)
Things aren't as easy as you'd like them to be ;-) and you'll probably end up with lots of symlinks (depending on which webapp you package of course).
So what? I never said distribution packaging was always easy.
The question is how hard we (packagers) should make our live.
Is it really worth the effort to split a webapp to 4 directories (config in /etc, "immutable" files in /usr, data in /var, everything symlinked together in /srv - did I forget something?)
No need for the latter part. You can serve directly from /usr/share/php, having links to config and mutable parts from there.
Generally, I am not interested in discussions IF applications should be packaged. This is the packaging list after all and we are discussing because we currently have not yet found answers how to handle things.
Personally, I'd simply package everything in /srv and - restrict write permissions to the places that need to be writeable - set open_basedir restricted to the webapp's directory [2] - optionally session.save_path, upload_tmpdir etc. set to a specific directory - set a "deny from all" for directories that shouldn't be public (for example smarty's templates_c directory) - maybe even include an AppArmor hat?
I know this is not strictly following the FHS ;-) but it has a big advantage: users/admins always have the same directory layout of the webapp - independent of the question if they use a rpm or install from a tarball. In other words: it's less confusing ;-)
Symlinking the config file(s) to /etc/ would be OK, but everything else doesn't bring an advantage IMHO.
(Note that I'm talking only about webapps - for PEAR packages etc. a location in /usr makes a lot of sense.)
It's a fine line. Pear packaging isn't about libraries only. If we install our pear stuff more or less FHS-like, we should at least try and provide other apps in a similar style where this works. It's not so much about religious belief in FHS. People seem to like having configs in /etc/, all in one place. I've seen systems with /etc/ being a subversion repository or backupped daily. I think we begin repeating ourselves. - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk87am8ACgkQCs1dsHJ/X7C3hwCgyjIkNJKbR/TEAli9PfYviyg3 PasAn01dX2fmVhu0hiSBe8MT3VGhRnQQ =tPiZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org