On Wed, Oct 13, 2004 at 11:16:09PM +0200, Agustin Martin wrote: > But for shared/* debconf templates this means that all packages using that > template need to be rebuilt against the new template-providing package > after every change in its template contents. I think that is better to > split the roles, one template contains the real template and is not shared, > something like: yes, it'd have to be rebuilt with the new templates every time they were updated, which is definitely a shortcoming. if there were a centralized set of templates in a run-time dependency (and it reliably worked wrt dependencies) that'd probably be the best way. > So things like the one below (in some sort of pseudo language, so untested) the problem with this setup is that if i understand it correctly, you're essentially sharing variables between all packages. in many cases the variable will need to be stored per-package (database,username). > AFAIK templates are all read and registered to debconf database before > the .config files are run. Pre-Dependencies stage (configuring packages on > which other pre-depend) takes place later. Why register would not work if > called from .config and the package containing the global question is also > being installed? I think a plain dependency is all what is needed to > make sure the global template is present and read at the .templates stage. no, i believe they're registered *by* the config, or whatever script first sources the debconf library. so, a template-providing package must already be pre-configured before debconf questions will work. *however*, the config script is run once again before the postinst, at which point you're guaranteed that the package is pre-configured. asking debconf questions at postinst time is kind of frowned upon, but i think it's open for discussion whether it'd be okay in this case. > By the way, REGISTER looks a really nice approach for questions having > an essentially similar debconf template (not to be messed with shared/* > debconf templates). It might even be useful for shared/* questions instead > of the above schema. i really like the register idea as well. On Thu, Oct 14, 2004 at 12:08:42AM +0200, Brian Sutherland wrote: > How do you then solve the problem of the translations and such becoming > out of date? rebuild the packages. i wouldn't put it totally out of question, but it's definitely a little clumsy. > > unfortunately means that the REGISTER suggestion won't reliably work, > > which is really too bad because that would have been the most graceful > > solution. > > What do you do instead of REGISTER if each package wants to have it's > own question? Change the directories of the questions when copying? maybe something like what was mentioned above, though i'm beginning to think register might work after all, providing a) it's acceptable for debconf to be run at postinst time, or b) the package could fail gracefully through the postinst. > > over the past week i've been in contact with joeyh about the > > feasability of doing this with a debhelper-style script, and think > > i have the workings of a primitive version hashed out with him. > > Thanks, Great!! let me know if you need somebody to test it. (or even > help) okay. sometime between now and this weekend i'll put some proof of concept packages (a debhelper style, runtime style, and a fake package that depends on both. also, i've started up a very rough draft of a "best practices" page: http://people.debian.org/~seanius/policy/dbapp-policy.html which could use tons of input from the maintainers of database using web apps, database servers, and anyone else. it'd be nice if at some point a policy could even be adopted from it, but even existing as mere suggestions would be nice. sean --
Attachment:
signature.asc
Description: Digital signature