[debhelper-devel] [dpkg+debhelper] On declarative packaging and dpkg metadata

Niels Thykier niels at thykier.net
Sun Aug 23 13:30:24 UTC 2015


Hi,

Guillem and I had a chat at DebConf about making packaging more
declarative and dpkg metadata - these are the notes, I wrote down.

 * Use a spec/manifest to declare what is in the package (e.g.
   mtree-like).  This could store (among other things) the following
   metadata about each file:
   - ownership (owner+group)
   - permissions
   - "is_conffile"
   - checksums
   - symlink targets ?

 * The manifest would (eventually?) replace the md5sums and conffiles
   files in the control.tar of the deb

 * Implementation-wise, this manifest can be created at install time and
   eventually be used to the packaging stack.
   - When moved to the packaging stack, it could be used to remove the
     need for building as (fake)root for many packages.
   - Also, this will probably replace a lot of debhelper files/tools
     (e.g. dh_install)

 * The manifest would be used to assist dpkg keeping better track of
   what the (pristine) system state should be.  It might replace (or
   extend) existing internal dpkg databases (e.g. the *.list files).

 * Some declarative things to be moved into dpkg:

   - The mv_conffile/rm_conffile
   - Diversions

 * Declarative alternatives:
   - It was not clear whether alternatives handling should be
     integrated more closely with dpkg or it should be more cleanly
     separated from dpkg
     - I admit being a bit fuzzy on the details here.
   - Mean while, debhelper can create a prototype declarative
     alternative handling
   - The basic idea is to create an "alternatives" file that declares
     the alternative(s).  The format is listed in [1]
   - The developer provides the file and debhelper includes it in the
     control file.
   - In the prototype phase, debhelper will generate the maintscripts
     required to register the alternative.
     + Once dpkg is ready to work with the file itself directly,
       debhelper will stop generating the scripts.

 * There was a suggestion about providing "declarative modules" or so.
   - The idea was that things that are /not/ dpkg specific could be
     provided by another package/tool (It would probably have to
     essential or/and only rely on essential packages)
   - If alternatives are not integrated tighter with dpkg, this could be
     a way to implement declarative provides
   - If created, it might also be used to create a method for handling
     services (simple cases).

 * dpkg should be able to track configuration files (not conffile) by
   packages registering them.
   - Intend to replace ucf/ucfr

 * I would look into replacing the ldconfig calls in maintscripts with
   an active trigger.
   - There is a possible issue with the trigger being called in
     "irrelevant" states, which may be a non-issue.
   - The glibc maintainer already has a trigger for this purpose (inside
     /sbin/ldconfig, which is now a shell script).  This change would
     promote said trigger to an "external" API of the libc-bin package.
   - This would also involve -devel and (eventually) -policy.


[1] Format we discussed was based on the update-alternatives --query
format.  It is a Deb822 file with 1 or more paragraphs (one per provided
alternative).  An example could be:

Name: editor
Link: /usr/bin/editor
Alternative: /usr/bin/vim.basic
Slaves:
  editor.1.gz /usr/share/man/man1/editor.1.gz
  [...]
Priority: 60

With "Slaves" being an optional field.  If a package provides multiple
alternatives for the same link, there will be a minor duplication (Link
and Name being repeated), but we deemed it to be an unlikely case.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20150823/ab14357f/attachment.sig>


More information about the debhelper-devel mailing list