On 11/17/21 8:18 PM, Zack Weinberg wrote:
However, I think it was the responsibility of the developers of usrmerge to find out how bad that problem actually was, rather than dismissing it. And, as it has proven to be a genuinely critical problem, it is also their responsibility to fix it, per the 'no one can be forced to do anything' rule.
At least for this email, I'll stipulate to everything above.
Is this particularly hard to fix, though?
Can't we just do something like the following pseudo-code:
----
/* At dpkg start... */
usrmerged = FALSE;
if (the_flag_is_set) {
usrmerged = TRUE;
} elif (bin symlinked to /usr/bin) {
usrmerged = TRUE;
/* Update e.g. /bin/foo to /usr/bin/foo in the database. */
update_database();
set_the_flag();
}
/* As dpkg is deciding to write a file path into the database. */
/* e.g. the package is trying to install to /bin/foo, put
* /usr/bin/foo into the database. */
if (usrmerged) {
path = canonicalize(path);
}
----
(I've used /bin -> /usr/bin as an example, but the canonicalization must
deal with the other merged paths too.)
The second bit ensures that all new operations write canonicalized paths (e.g. /usr/bin/foo) into the database regardless of whether the .deb shipped with /bin/foo or /usr/bin/foo. This ensures the database stays in sync with the filesystem moving forward.
The first bit performs a one-time canonicalization of paths in the existing database. An on-disk flag ensures that this is run only once (for performance reasons only, because it's already idempotent). This corrects the existing database-filesystem mismatch.
The one-time canonicalization can be removed once non-usrmerged systems are no longer supported. The second bit needs to live (probably a lot) longer, until it's no longer reasonable to install a .deb containing non-usrmerged paths (which might be old or from a third party).
Am I missing something here? -- Richard
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature