Le Mercredi 4 Mai 2005 16:26, Alexis Sukrieh a écrit : > * sean finney (seanius@debian.org) disait : > > they would only be prompted if they modified the file *and* the > > "static" version of the file changed. > > Then, we definitely have to use ucf for installing static files. > > > > 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. > > Could you give us details on what you have in mind? > > What I've understood is the following: > > - /usr/share/$package is the documentroot of the webapp, thus > every static files have to go under this directory _and_ should not > be touched by the user. > > - the webapp package provides a directory /usr/local/$package > > - 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. this is one solution, but not the only one. take an app that comes with some plugins by default, and where all plugins have to live in the same dir. if you want the user to be able to add his own plugins, and that you cannot/don't want to patch the app to support multiple directories, .. then you can put the plugins in /var, because we can assume things about what lives here, whereas we cannot assume what lives in /usr/local. > - The package provides a /usr/share/$package/debian/ directory > which is a temp location for the postinst purposes. certainly not, that would mean that /debian is under the docroot of the webapp, that is bad. moreover this duplicates a lot of files and wastes space for ppl using the pristine app. > - 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 I'm not sure we have to do this in fact. we have to say "we support templating for that package" or "we don't". And we should bug upstream to support sane templating mechanisms (through any method where a new theme is equivalent to ( new files + some config ) and does never alters the content of the site). Then, if a user still want to change the app look'n'feel, then he has to manage that by himself, e.g. by dpkg -X /srv or using customs installs. and if we support it, then we should have a way to let the user 'divert' the content by one way or the other. but ucf won't give good results on template files as soon as the user changes too much indent or line break, this will fail. -- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Attachment:
pgpheO6cgY9_I.pgp
Description: PGP signature