hey folks, i'd like give my thoughts on what we currently have in CVS, and solicit some further comments. below is an annotated version of the draft. let me know what you think! > 2 Common issues and recommended solutions > type of file location > --------------------------------------------------------------------------- > Architecture independant Perl libraries /usr/share/perl5/PACKAGE > Architecture dependant Perl libraries /usr/lib/perl5/PACKAGE i don't think we need to mention these two, because they should already be covered by the perl policy. perhaps we should have a reference to that instead? > Template cache files /var/cache/PACKAGE/templates what are template cache files? > 2.2 Static files > > FIXME : there are two main points of view for static files, remains to choose > which one to keep. > > * Static files are conffiles * > > ... > > * Static files are readonly data * i've said it beofore, and i'll say it again... static files should DEFINITELY be readonly data. we make everyone's life easier if we say that. for those who absolutely want the ability to edit all of these files, we've discussed the feasibility of generating a tool that would assist in this, and it seems fairly reasonable that we could do it. > 3.2.2 Registering and unregistering a php module > > FIXME sukria : should such a piece of code be provided by a webapps-common package? definitely. however: > An entry should be placed in the relevent php.ini using postinst, if this is OK by the admin. i think it would be better if php provided directories like /etc/php4/apache/php.d. this way packages could simply place files in this directory, instead of having to edit the php.ini file manually. the php packages currently don't provide this, but we must remember that many things in this draft do not yet exist :) > 3.2 Perl modules handled in the perl policy. > 4.1.1 Symlinking the document root > > One of the easiest way to register the web application with the web server is to > symlink the document root of the web application under /var/www. > > For instance, a web application is likely to put its document root under > /usr/share/bugzilla/www (as suggested on section 2.1) and should then add a > symlink like that: > > /var/www/package -> /usr/share/package > > This is the easiest way to make the web site visible from the web server > (accessing http://host/package/ is now possible). i'm going to disagree with this. i think that the applications should be completely agnostic of the document root, and provide access to themselves via apache aliases (or the equivalent). some reasons: - it will be much harder to preserve the admin's preferences on upgrades (it would be hard to not recreate symlinks the admin deleted) - it makes assumptions about where the documentroot is - it could fail or overwrite non-package pre-existing data in the documentroot > 4.1.2 Adding a Location to the webserver configuration > > There is a more complex way of regitering the web application which may be > better than the previous one there are two very similar aproaches to this i'd like to discuss. 1: place the webserver config in /etc/$package/apache.conf. then, symlink to that to /etc/$apache/conf.d/$package.conf. 2: place the webserver config in /etc/$apache/conf.d/$package.conf directly. there is a subtle difference between these two aproaches. 1 will be harder to maintain the admin preferences across upgrades (same symlink removal problem), but makes de-activating the config easy to do without moving/removing the actual file. the second one will cause problems in the current apache config (because they include conf.d/*), when dpkg leaves behind $package.dpkg-new type files. also, 2 might break some apache installs when the package is removed but it's conffiles remain (and apache is restarted). > 4.4 Providing different upstream versions at the same time i think this is outside the scope of our policy. sean --
Attachment:
signature.asc
Description: Digital signature