-----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----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org