This one time, at band camp, sean finney said: > 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? Yes. > > 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. Static data files really have to be package domain, rather than admin domain, I think, for sanity's sake. A mechanism where templates or custom headers could be added via symlinks back to /etc/$package would be nice, but is less essential, IMHO. > > 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 :) Fully agreed here. All direct editing of config files in postinst is fragile, and I'd love it to go away (so says Steve, who maintains several packages that edit config files in postinst :) > > 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: Agreed. The document root is absolutely irrelevant to apache configuration. It just provides a convenient, simple place to dump things. Since we are talking about common infrastructure, it wouldn't be hard to write a dh_webapp or somesuch that provides a decent default apache.conf for the package. > - 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). The symlink approach is the better one, at least according to policy, I would think. Just remove the link on --remove, and the package is disabled without removing configuration files, which should only be done on --purge. If apache*'s include directive has not been patched to ignore .dpkg-* files, it should be, although that's up to the apache team, I suppose. This is a pretty standard patch for most programs that are in Debian, so it would not be an unreasonable request. The admin preferences issue is fairly simple - if $2 is empty, it's a fresh install, so set the link. If [ -n $2 ], then it's an upgrade, so do nothing. This may not be perfect, as it won't recreate the link for a clueless admin unless they remove and reinstall the package, but clueless admin's seem to frequently do those sorts of things anyway :) > > 4.4 Providing different upstream versions at the same time > > i think this is outside the scope of our policy. I agree. However, having a common infrastructure for providing different config files and set ups for a single install spread across multiple vhosts would be nice. p.s., good to see you on the list, too, sean. take care, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgp5yjQlnuIIn.pgp
Description: PGP signature