Re: annotated version of current CVS policy draft
* sean finney (seanius@debian.org) disait :
> 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!
Good idea, we should not forget to discuss important points here, on the
list :)
> > 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?
I agree, I just put those lines to underline the fact that a webapp
*could* put a specific Perl module for its purpose. For instance the
2.18 bugzilla package installs /usr/share/perl5/Bugzilla in order to
provide the Bugzilla::Foo modules.
But it could be just a reference to the Perl policy, indeed.
> > Template cache files /var/cache/PACKAGE/templates
>
> what are template cache files?
I meant cache files that could be generated by templates tools such as
Template::Toolkit for instance. It's a kind of precompiled tempates if
you like. Most of the time, that's in the scope of the template tool
though...
> > 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.
Great, I aslo think that claiming the readonly state of our static files
is the right thing to do. I just thought that some of us prefered to use
the conffile solution.
> > 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 :)
Agreed. This is the best approach to me. I also think that this policy
will lead us to contact a lot of team to adapt their packaging to what
we recommand here: the apache and php team would certainly be the most
important ones.
> > 4.1.1 Symlinking the document root
> > [...]
> >
> > /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 completeldfy 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
Ok, but I'd like to underline that a lot of webapps currently behave
this way. We'll have a lot of bug reports to fill if this is a violation
of our upcoming policy ;)
> > 4.4 Providing different upstream versions at the same time
>
> i think this is outside the scope of our policy.
I thought we spoke about that.
--
Alexis Sukrieh <sukria@sukria.net>
http://www.sukria.net
« Quidquid latine dictum sit, altum sonatur. »
Whatever is said in Latin sounds profound.
Reply to: