Le dim. 17 sept. 2023 à 21:26, Russ Allbery <r...@debian.org> a écrit : > 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.
Yes, it's better to keep dpkg clean & generic and handle the fast moving parts elsewhere. (like not tainting dpkg forever with the oneshot UsrMerge final migration) I understand why redhat would bolt tmpfiles directly into rpm, but it's a more integrated ecosystem. > 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. Yes. And debputy too, which is a rewrite of debhelper, but in Python, with different assumptions (everything in one machine-editable yaml instead of so many tiny files in debian/ ) > those files. and not only files but glob patterns: /var/cache/[package]/** > 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. Yes, that's what dh_cruft does. I use it extensively for my proprietary Debian-derivative, but did not try to push it down Debian packagers (because it's in Perl and I cannot really maintain it, so the tmpfiles.d parsing is not there yet). Having today machine readable data (instead of "if $1 == purge... rm -rf ...") make it easier to later turn it into another packaging format. > This design is just off the top of my head, and I'm probably missing some > problems and some details. You've got a good grasp of the important parts. So this tool can be used to recover trashed system - I receive 10 years old filesystem images that have seen much "sudo make install" abuse - but also be used to make the distribution better as a whole. So I file bugs regularly against random _other_ packages for the dynamic things piuparts won't notice by design; because it doesn't run the tools in packages it tests. (most of the times it's a missing "rm .." in postrm); Maybe having cruft run in last step of all autopkgtests would ensure all dynamic files are registered. (maybe only on Salsa first) The first step would be that autopkgtest itself provides this authoritative list of allowed file names. (see from : ---- unexplained: / ---- ) https://ci.debian.net/data/autopkgtest/testing/amd64/c/cruft-ng/37993513/log.gz Greetings --- I uploaded a new "cruft-ng" with a new "cruft --package PACKAGE" option that dumps this one package volatile files ruleset to ease import in another tool. And "cruft FILE" now works closer to [ "dpkg -S" + volatile files ].
