With the huge breadth of software available in debian, there exist many groups of packages which either require or are enchanced by "extra work" done on the part of the package maintainer. For example, many packages require a mysql/postgres database or to be configured for a web server. The more complicated the task, the more likely it is that portions of the involved code/translations/effort is duplicated/incomplete/buggy.

The driving focus of the talk is to analyze how such tasks can be abstracted, isolated, and consolidated into a common infrastructure. The benefits of such an infrastructure for packagers, translators, and users alike should be fairly self-evident.

In this talk I will heavily rely upon the lessons learned from my own work to develop a common infrastructure for database applications, as well as the nascent web applictions project. However, the concepts and techniques discussed are applicable to a much wider range of issues affecting debian packages today.

Outline:
- Above summary
- Database applications
- The problem
- Previous efforts to address the problem (wwwconfig-common)
- Summary
- Inherent problems/limitations to this approach
- only the "do it" code (which had its own problems)
- still much redundant code in maintainer scripts
- does not address debconf+translation needs
- result: still very inconsistant
- Initial attempts: build-helpers (debhelper/cdbs)
- Summary
- Inherent problems/limitations to this approach
- large amounts of (volatile and potentially
buggy) code are introduced into maintscripts.
- no way to enforce new versions of code to packages
- result: build-dependencies are not the way to go.
- dbconfig-common
- spend a while discussing what it does, how it works
- show it in action (sandbox install)

- Lessons Learned
- do:
- consolidate code into shell/perl/whatever libraries
- require minimal amount of code in maintscripts
- "do it" logic, and maintscript logic should be covered.
- centralized debconf templates (via debconf REGISTER/SUBST)
- centralized debconf templates (no really, this is huge!)
- do not:
- standard list of bad things

- Other Future Applications
- web applications (reference webapps-common project)
- adding/removing system users for packages
- a better solution for python
- overlapping services (httpd, inetd, smtp, imapd, etc)
- logfile handling
- pam modules

- Q & A