hi, On Wed, May 04, 2005 at 09:39:27AM +0200, Alexis Sukrieh wrote: > Well, ucf might be a good idea. I already use it in bugzilla for moving > a config file. But note that if we use ucf for moving every static files to the right location, the user will be prompted for a merge if the files changed from previous version. they would only be prompted if they modified the file *and* the "static" version of the file changed. > IMHO, the first thing to do will be to claim that "static files under > /usr/share/$package must not be touched". > Then, we can implement such a system (with ucf). i agree. it wouldn't be too hard to throw together a tool that registered and tracked these "copy" directories, and when a package was updated there could be a hook in the postinst script to look for all of these directories. a cron job could help out too. On Wed, May 04, 2005 at 10:03:16AM +0200, Pierre Habouzit wrote: > My understanding of the problems (templates, plugins, ....) is that we > won't be able to find a perfect general solution, since every single > webapp use its own templates, its own plugins, ... yeah, and what "plugin" means to one web app is different than another. i think some general rules could be applied though, and there's always the FHS to tell them where they should go. > e.g, we could say that a webapp that uses a SGDB has to provide : > > db_create > db_delete > db_save > db_restore > db_upgrade why should the webapp have to provide that functionality? that would be quite a bit of duplicated effort. plus, as previously discussed we shouldn't be spending any time worrying about the database related issues here, as that's already taken care of for the most part. > and that *every* single webapp should provide : > > cfg_new (to create an instance) > cfg_delete (to delete one) > cfg_is_multiple (does the app support multiple instances > in its actual form) again, i smell duplicated effort. the webapp packager should only need to provide information about itself to the automagic configurator. *maybe* some hooks would be helpful, but only if it needs to do something really out of the ordinary. plus, as i've said before, let's not leap before we look. save the api design until we know what the problem fully (or mostly) is, and what we want the tool to do. i'm going to remphasize, imho, that we are not ready to talk about packager apis and/or code design yet. > So now that we already have a quite long list of common problems (that > will grow, but we can deal with it incrementaly) maybe we should list > all the features we (may) want, and then decide if we only list those > in a policy, and let the maintainers deal with this list, or if we > provide some fancy tool like I suggest (or any other solution we can > imagine) okay, here's a few things that any system would need to be able to do, from an abstract perspective: - support "drop-in" configuration file installs - start/stop/reload web servers - detect running web servers - support directory/virtualhost installs - support multiple directory/virtualhost installs - help manage outside-of-usr copies of static document trees. - register php/web-server add ons sean --
Attachment:
signature.asc
Description: Digital signature