Re: booststrapping /usr-merged systems
Helmut Grohne <helmut@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: