2224
Comment: Note another use case for declarative packaging modules
|
2440
Add reference to sysuser spec draft
|
Deletions are marked like this. | Additions are marked like this. |
Line 28: | Line 28: |
=== Declarative diversions === Please see the mail reference above. There was also a failed GSoC some time ago SummerOfCode2011/DeclarativeDiversions. |
|
Line 35: | Line 40: |
* Adding system users | * Adding system users (and removing them on purge) [[Teams/Dpkg/Spec/SysUser]]. |
Status: draft
Summary
This proposal is about making common install/upgrade/remove operations in binary packages declarative. In particular, it aims to remove many of the common needs for maintainer scripts.
Please usertag bugs with:
- usertag: declarative-packaging
Recent examples of this are 685734, 822462, https://lists.debian.org/debian-devel/2015/08/msg00412.html
Proposals
This specification consists of many "smaller" projects to replace maintainer scripts (or other imperative packaging methods).
TODO: Review and add items from https://lists.debian.org/debian-dpkg/2015/08/msg00031.html
Integrate dpkg-maintscript-helper features into dpkg
Methods in dpkg-maintscript-helper are basically features that ought to have been in dpkg.
Declarative diversions
Please see the mail reference above. There was also a failed GSoC some time ago SummerOfCode2011/DeclarativeDiversions.
Declarative packaging modules
A lot of packages have common functionality that is not directly specific to what dpkg should provide. As an example, start/stop/restart of services.
If we could outsource such functionality, then other packages could provide a declarative function that other packages can depend on. It could be used for:
- Start, stop and restart of services (the common cases).
Adding system users (and removing them on purge) Teams/Dpkg/Spec/SysUser.
- Alternatives handling (assuming it is not tighter integrated with dpkg)
- ... your idea here ...
Such declarative modules should probably be very restricted in their requirements (e.g. only need essential packages).
Get rid of incomplete/indirect "triggers"
We got some (possible) indirect triggers where a tool has been rewritten to call dpkg-trigger instead. Presumably these should migrate to "activate(-noawait)" triggers instead of requiring a shell script.
Possible instances:
ldconfig - Fixed in debhelper with lintian warnings to clean up the remains
update-initramfs - 822730
update-mime-database - Needs investigation (might be leftover from a trigger migration). See https://sources.debian.net/src/shared-mime-info/unstable/debian/wrapper/?hl=13#L13