I'm heavily symlinking all the sources from /usr/share/NAME to /var/lib/NAME/webroot ; in /var/lib/NAME/webroot configuration, extensions and templates can be configured and the application can have write-access, too. Additionally I add /var/lib/NAME/temp and /var/lib/NAME/sessions directories, which are configured for php to be used for uploads and session information. As PHP is per configuration (in /etc/apache2/conf.d/NAME ) not allowed to access files outside /var/lib/NAME and /usr/share/NAME, the applications are configured in a very safe way. An advantage is, that its quite simple to use the same package for different virtual hosts (which is a as requirement in LSB, when I remember right). It's not important for web-mail tools, but its nice to have eg. for packages like mediawiki... In this case the installation un /usr/share makes also sense, as the sources are used from different vhosts. The package structures are also compatible with other distributions. Disadvantage is, that for some applications you must sometimes add patches to work correctly with symlink-structures.. Johannes Am 14.02.12 06:56, schrieb Ralf Lang:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 14.02.2012 00:36, schrieb Christian Boltz:
Hello,
Am Montag, 13. Februar 2012 schrieb Ralf Lang:
A lot of pear software adheres to separation of config and data, other things can be patched to work this way.
Proposal:
1) Immutable parts of web apps live in /usr/share/php5/* (install tarballs) or /usr/share/php5/PEAR/* (if they are pear packages(
Define "Immutable parts", please ;-)
Parts which are not expected to be changed. You don't expect users to do weird hacks in an application's core files when installed via rpm. In an rpm-provisioned system, the correct deployment for a patched application is a patched rpm.
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)
- 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.
- 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.
- webapps that allow to update themself online (like wordpress - and no, I won't be surprised if I see a *shudder* from Ludwig because this requires write permissions for wwwrun on the whole webapp)
If you want your app from rpm / from distribution, you also want updates via rpm / from distribution. If you don't like the way the distribution handles stuff, you can always "download and unzip". For example, while it is technically working to upgrade an rpm-installed pear library or app via pear upgrade or by replacing files, it is not the best idea. You will bring yourself into trouble. If you want manual gui updates decoupled from the distribution, you better get a tarball.
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.
If you implement something like this, please make sure to find a solution that - won't cause lots of files in /etc/apache2/conf.d/ to be marked as "modified" by rpm (which makes updates more interesting - I don't like the idea to merge and cleanup 100 *.rpmnew or *.rpmorig files) - won't lock the webapp again after an update
Agreed.
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. Any scheme we agree on should have sane migration paths and only migrate parts when they are working. Users will always have the option to generally not use a distribution-provided app but when they do, they should get an app that behaves like any program in the distribution. I certainly won't reject anything for s:p:a just because a packager does not try arcane tricks to make apps work this way which simply can't by design.
- -- 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/
iEYEARECAAYFAk8594kACgkQCs1dsHJ/X7DE3gCgjvHbeMVUV2TJLL2ZgKOyyLeO vC4An1SDkmf/aAhsRgPXnn3k9jAGzF47 =bIBg -----END PGP SIGNATURE-----
-- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org