Hello. I think triggerer packages information should be exposed to triggers. In example we may want to have an index of information about installed packages in a form better suitable for lookup than files in info. I.e. a trie for file paths mapping them to packages. But this DB has to be updated. We can either update it fully on each installation, which is long, or selectively only for the packages installed. To do it we need the info about the packages installed be passed to triggers and hooks. I have implemented it partially (only for installation) in https://github.com/guillemj/dpkg/pull/3 . It serializes some info using bencode into an env variable. 1 serialized value in 1 env variable is chosen over multiple env vars with delimiters because it is easier to process it in scripts and more succinct. Bencode is chosen because it is text-based (env variables cannot contain arbitrary binary data, such as zero bytes, so unfortunately we cannot use CBOR/MSGPack/BSON), requires no characters escaping in strings, is easy to be implemented in C and mature enough to have libs available for langs. https://github.com/guillemj/dpkg/pull/3
Attachment:
info.patch
Description: Binary data