Helmut Grohne <hel...@subdivi.de> writes: > Indeed. However, if you actually manage to trigger this, it can be very > surprising. Your hard coded list would also contain /lib32, /libx32 and > /libo32. Then you install some mipsen packages, remove them and wonder > why /libo32 does not go away. piuparts is definitely unhappy at this > point. I am quite sure that this behaviour would break something. What I > am not sure about is whether accepting such breakage is a reasonable > trade-off.
Compared to most of the problems we've discussed on these threads, this seems like a very unimportant problem and a very acceptable trade-off. We can just change puiparts to not care. It's not *idea* to have a dangling symlink that points to a nonexistent directory, to be sure, but given that normal UNIX symlink semantics treat that symlink as identical to a nonexistent file/directory unless you go out of your way to treat it as a symlink, I find it hard to imagine what specifically would break, and am therefore much less sure than you are that this would break something. (Other than QA tools like piuparts, which IMO don't count. A failing test case doesn't necessarily mean a real problem; it can mean that the assumptions the test case were written under have changed. One has to look at the specifics to see whether there is a real problem or whether the test case should be changed.) On the other, related topic, I've also been somewhat confused in this discussion why it seems like there's a long-term goal to not have any Debian package ship the /bin and /lib symlinks. I would assume we would keep those symlinks forever, and thus will always be shipping them in a package from now on (once we get to a place where it's safe to ship them in a package). In the long term, that seems like the most efficient way to prevent them from being removed, and also just seems obviously correct semantically. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>