[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