Hi Helmut, On 24-08-2023 17:46, Helmut Grohne wrote:
In this mail,I'm concerned with P6, i.e. loss of empty directories.
[...]
This inconsistency is detected e.g. by piuparts, which may fail. This is how Andreas Beckmann originally discovered this problem class.
Ack.
As a result, I've started filing patches for this problem class. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=dep17p6
Thanks.
In the majority of cases, such empty directories are more of a bug than a feature and we can simply delete them. In some cases, they really are used though.
Can you elaborate? My imagination might be limited, but all I could come up with is that maintainer scripts expect a directory to be there and try to write to it without checking (is that also the case for the issue that you referred to in [1] mentioned by Jochen?). I *think* that if a package needs the directory to installs a file into, the directory will be created (or will dpkg fail as it assumes the directory already exists)?
When they are used, we need to do something about that deletion and I've submitted e.g. https://salsa.debian.org/systemd-team/systemd/-/merge_requests/208 where I got negative feedback on the need to address this.
Which has been fixed nevertheless.I agree that *only* pleasing piuparts is not the best time spent by maintainers, *if* that's really the only problem we're solving. I guess we're having a hard time with this check to find a real life problem. I *think* that https://bugs.debian.org/1050606 (linked from that MR) points at an example of this problem, right? So that's at least one.
So how important is it to have these empty directories? I concur with Michael on the aspect that their loss rarely poses a practical issue. It can make piuparts fail however and when it does, the failing package tends to not be the one that is able to fix the failure. So in effect, keeping these bugs would cause latent migration blockers. For this reason, I was assuming the bug class to be release critical. Do you concur?
If everybody agrees that the only place where this causes real life issues is piuparts, than I rather have piuparts ignore this problem. After we're fully canonized, are we safe again and could we turn the check on again? Looking at that example bug above though, I'm not sure we can only see this class of problems in piuparts.
If we want it to not be release critical, I think we'd have to augment piuparts in a way that it ignores such directory loss.
Ack. Piuparts is a tool to detect problems. While technically correct, we can ignore classes of problems if that serves us better than fixing them.
On the flip side, systemd has been the last package for me to file a patch where this issue has practical consequences already. All others have been filed already. Beyond these, there are five more cases on the horizon that likely need to be mitigated when we lift the moratorium.
With patches ready?
So while the mitigation is ugly, the low number of affected packages and the temporary nature of the mitigation made me conclude that doing this is a reasonable trade-off. Do you agree? Another example for the ugliness is #1050412.
Will the next time that pkgconf-bin is installed (reinstall or upgrade) recreate the directory again (without your patch)? Or will the directory be lost forever?
I'm not totally sure you got the answer to the question you raised, but I'm also not totally sure what you wanted to hear.
Paul [1] https://lists.debian.org/debian-devel/2023/05/msg00325.html (udev)
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature