[Comment for reviewer]: The UX on this one is not ideal. There is a balance between being general enough that Ubuntu packagers might look at the output of this script to fix packages upstream and being specific enough for a Chisel developer to fix the issue quickly.

What we could do is experiment with the current version and improve the error messages once we see real usage in chisel-releases, because documentation might be all that is needed (e.g. CI outputs a message saying how to fix the issue by checking all slices for explicit path or essentials with the folder).

Why would the path have to be listed in all slices, and why are immediate essentials different from non-essential ones? I don't recall that being part of the original discussions, and I'm missing how these constraints would affect whether a conflict is supposed to be reported or not. If we have path shared in different packages, our anti-conflict behavior should kick in whether it is in a single slice or multiple, and essentials don't even play a role there.

We'll need to sync about the premise again. Otherwise, the overall logic is clean and looks good.

I had written a comment in Github before you reviewed but somehow it was not published, apologies for that. I discussed this with Cris and wanted to also discuss it with you, let me write it here and we can talk about it in our next meeting. There are a couple of simplifications/conventions I think we should consider to reduce the scope of the problem and to lead to better UX:

1. If a package contains the wrong directory (e.g. /lib) then all slices should point to the correct one (/lib -> /usr/lib), even if the slices don't contain a path that could extract the directory.
2. A package might declare the directory explicitly or it might be listed in the immediate essentials, we will not traverse the essential tree recursively.

The reason for 1. and 2. is that we want to avoid users adding concrete paths to slices or creating new slices for an existing package and then some obscure script in the CI breaking telling them about parent directories; that will make it very brittle in an unexpected way. By doing 1. I expect the changes to the package to only happen once, when adding it to the release. At that time, we will add a package-level essential and that's it, problem solved. No one has to worry about this issue for this package ever again. For 2. the reason is that if we were to recursively check all essentials we will end up with a web of dependencies that might also break unexpectedly, e.g. by removing one path from an unrelated package I may be breaking another one up the chain, again with a CI script that users will not test locally.

For me, these reasons above about UX justify the change but, on top of them, there is also the issue of how complex we want this to be. At the time of this writing we have only 4 conflicts in a release and all of them are due to the /lib, /usr/lib (or /bin) split, I don't think we should spend a lot of time trying to avoid all false positives if we don't have any in the first place and this leads to better UX.