On Wed, May 04, 2005 at 04:26:45PM +0200, Alexis Sukrieh wrote: > What I've understood is the following: yes, that's the general idea of what i was getting at. a couple modifications though: > - the webapp package provides a directory /usr/local/$package i don't think the webapp needs to necessarily provide this directory, since there's a good chance the admin may want it somewhere else anyway. > - A note is provided (either a debconf note or a README.Debian > entry, ...) to underline the read-only state of files under > /usr/share/$package. The note also points the user to /usr/local/$package > for customizations. i think simply mentioning this in the policy would suffice. > - The package provides a /usr/share/$package/debian/ directory which > is a temp location for the postinst purposes. > > - Static files go under /usr/share/$package/debian/static/ > > - At postinst time, a ucf recursive system (maybe a tool we'll > write) will take any file located under > /usr/share/$package/debian/static/ and will move it to the right > location under /usr/share/$package no, i think that the packager could just put the files where they normally would (something like /usr/share/package/htdocs or similar), which are then handled as any other files under /usr. if this is sufficient for the admin, nothing else happens out of the ordinary. if the admin wants to keep a locally modified tree of these static documents, they can use $magicutility which copies this tree somewhere else (where they specify), and somehow (config file, registry) registers where this new location is. then, in the postinst for any webapp, it will check for any locally copied/modified trees for said package, in which case it will call the $magicutility to update the tree as part of the upgrade process (and perhaps even ask the admin if it should). note that i've made mention of ucf, which i think could fit the bill for such a need (inside a larger chunk of code), but there might exist a better tool for the job that i don't know about. in any case, i think the underlying guts aren't as important as how such a system would work. > Feel free to comment on that. Please give me details on the cron job you > have in minde. What it is designed for? the cronjob was just an afterthought for cases where the admin never got around to updating the locally copied tree, as a reminder (kind of important for security related reasons, i was thinking). > For instance, every debconf screens implied by the db related stuff will > be ownled by dbconfig-common. That means only one set of scripts to > translate, only one way to do the db stuff (we then centralize problems > on a single point) and moreover, that's better for the end-user: he has > always the same kind of messages. exactly. the same thing for webapps is a must, i'd say. it makes things nicer for the local admin, because it's the same look and feel for every installation, and likely less buggy. for the developer it's nice because there's a well documented way to package it that involves hardly any effort on their part. and let's not forget the translators, who only have to translate a set of messages once, even if there are 200 applications using said templates. so in otherwords, such a package is a good way to make friends :) sean --
Attachment:
signature.asc
Description: Digital signature