15:32 <farkuhar> over in #crux, pkgadd has been the topic of at least two discussions recently (three if you count the [notify] nvidia-fb). Meanwhile I've been thinking about FS#15 again. http://ix.io/4s0B <- A patch this simple might work in a few isolated cases, but I doubt it would handle every possible instance of filesystem collisions during upgrades.

15:37 <farkuhar> Anton contributed a more comprehensive patch shortly after the bug was reported: https://lists.crux.nu/pipermail/crux-devel/2006-July/001805.html But in order to address both FS#15 and FS#63, those patches introduced new data structures, and the CRUX team decided not to implement them.

15:46 <farkuhar> I was tempted to adopt Anton's approach and introduce new typedefs to solve FS#15 (leaving FS#63 for later), but then it occurred to me that pkgadd could obtain the necessary auxiliary information from the target filesystem, at least in the case where the symlinks are already present (as in Mark's example /usr/var/foo).

15:49 <farkuhar> More challenging is the case that jue mentioned in April 2013 (json-c 0.10 -> 0.11), and its recent manifestations in other ports like linux-firmware. It's these edge cases where the naive approach in http://ix.io/4s0B is more likely to fail.

22:14 <jaeger> Kinda weird issues that look simple at first but end up being hairy due to the aforementioned edge cases

22:14 <jaeger> A solution I've occasionally thought about (but not really talked about or tested) is preferring the existing condition when that comes along, but notifying the user that something unexpected happened

22:15 <jaeger> Because presumably the system was in a working/known good state before the problem was hit

22:15 <jaeger> Have NOT thought it through in depth, though

22:50 <farkuhar> I actually tested my simple patch against a contrived example (upgrading an already-installed libgee with a package that populates /usr/include/gee-0.8/ and creates /usr/include/gee as a backward-compatible symlink). The upgrade succeeded, with no complaints from the patched pkgadd.

22:55 <farkuhar> I also tested that upgrade in the reverse direction, and again it worked just fine. I expected at least one of those upgrades to fail, since realpath() should not know how to resolve the symlink prior to installing the modified package.