Re: templates, static documents, and plugins
* 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.
- 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
Feel free to comment on that. Please give me details on the cron job you
have in minde. What it is designed for?
> > 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.
Indeed, moreover impementing db_* in each package is not the right thing
to do IMHO. The idea is that maintainer's scripts should do only what is
dedicated to the package.
Creating a database, filling in tables or even updating right permissions
are actions performed by dbconfig-common.
If not, friends, we'll fill bug reports!
The point here, is to globalize stuff as much as possible, just keep in
mind that we want the webapp packages to behave in a smooth way.
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.
This is IMO the good concept we should try to adopt: centralize problems
in a single point (package), dedicated to one action.
To come back to the "static files" issue, we could imagine a package that
will provide helpers for registering some files as "static files" and
will then manage the move them itself.
--
Alexis Sukrieh <sukria@sukria.net>
http://www.sukria.net
« Quidquid latine dictum sit, altum sonatur. »
Whatever is said in Latin sounds profound.
Reply to: