Hi Luca, On Wed, Oct 16, 2024 at 07:46:17PM +0100, Luca Boccassi wrote: > But how can you be sure that nothing depends on it? How have you > checked that it's not needed? This logic has been there for many years
You can never be sure. If that were your bar for removing compatibility (and I know it is not), you could never remove any compatibility. You'd paint yourself in a corner where you can longer modify the code base for the fear of breaking something. Evidently, that is not how systemd is being maintained. Instead, it breaks (and fixes) stuff frequently and honestly that's the only way of making progress. I have strong clues however. A default bookworm installation on arm64 does not have /lib64. I also fed the necessary change into systemd's upstream CI https://github.com/systemd/systemd/pull/34804. It produced five failures all of which are on amd64 and unrelated. In particular, the ppc64el, s390x and arm64 ones that are affected, are ok. On the flip side, you repeatedly side stepped the reverse question: What is the purpose of these links? I am still missing an answer here. The way this would be approached on the Linux kernel side is merging the change given sufficient evidence (and I think the above CI results combined with the persistent lack of an answer from your side poses such evidence) and seeing what breaks. When stuff breaks, the change would be reverted recording what kind of use case needs the code (thus answering my question). Do you see any reason for not using the same approach for such a change in systemd? The fundamental disagreement seems to be this: * You don't want to remove these links on the systemd side unless there is a proof for them to never be needed. (<- cannot be proven) * I don't want to work around them on the base-files side unless there is evidence for them being needed. (<- no evidence presented thus far) Do you see any other way of resolving this? This is a classical overlap of responsibility problem. If all else fails, we might ask the CTTE if you agree. Helmut
