Differences between revisions 12 and 13
Revision 12 as of 2021-08-22 00:28:27
Size: 2432
Editor: GuillemJover
Comment: Unify admonition format
Revision 13 as of 2021-10-25 23:27:11
Size: 2954
Editor: GuillemJover
Comment: Add upcoming update-inetd declarative support
Deletions are marked like this. Additions are marked like this.
Line 33: Line 33:
=== Declarative update-inetd ===

The update-inetd package is being modified to support two types of declarative definitions in TOML format:

 * Any inet-superserver provider, will be able to ship a provider definition describing how update-inetd can use it, mostly for service restarts, but also to provide hooks.
 * Any inetd service provider, will be able to ship a service definition describing the inetd.conf entry instead of needing to call update-inetd explicitly, which will be called from a dpkg trigger.

  • 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:

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 update-inetd

The update-inetd package is being modified to support two types of declarative definitions in TOML format:

  • Any inet-superserver provider, will be able to ship a provider definition describing how update-inetd can use it, mostly for service restarts, but also to provide hooks.
  • Any inetd service provider, will be able to ship a service definition describing the inetd.conf entry instead of needing to call update-inetd explicitly, which will be called from a dpkg trigger.

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:


CategorySpec