Alexandre Detiste <alexandre.deti...@gmail.com> writes: > The ugly magic behind the curtain:
> ls /usr/libexec/cruft/ -1 > LOGROTATE -> that parses these for path > SERVICES -> added today reading this discussion, it reads > CacheDirectory= & StateDirectory= from *.service > TMPFILES -> that parses these for path > This whole thing, while being already usefull & used, > is more like a mockup of what could be a "perfect" dpkg. > These tiny shell scripts could be converted into something else > that plugs into dpkg ... for example tiny .so plugins that answer > which package own which dynamic file ? > (for runtime evaluation, other possibility is debhelper magic at > compile-time that generate a list of possible files) Based on previous discussion with Guillem, I think the direction Guillem is headed is something like adding a new member (or field in another member) to the deb format that holds a list of volatile files that the package considers itself responsible for. I think I agree with Guillem's position (at least as I understand it) that it doesn't make sense for dpkg to parse other files to populate that list. That can very easily be handled outside of dpkg. So the idea would be that the package would install tmpfiles.d files, service units, and similar files as normal, and then debhelper would parse those files, extract the list of paths that they manage, and use that to write a control file or the like that dpkg consumes to register those files. If I'm correct about that design, an intermediate step in that direction from where cruft is today would be to add that logic to debhelper and then have debhelper ship that database in the package in /usr/share/cruft/<package> or some similar directory, and then cruft could just consume that database of registered paths to get attribution information until such time as that can move into dpkg. This design is just off the top of my head, and I'm probably missing some problems and some details. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
