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  - 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.  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.
Description: OpenPGP digital signature