jaeger changed the topic of #crux-devel to: CRUX (https://crux.nu/) development channel | Logs: https://libera.irclog.whitequark.org/crux-devel/
rbnhn has quit [Remote host closed the connection]
henesy has quit [Remote host closed the connection]
rbnhn has joined #crux-devel
henesy has joined #crux-devel
farkuhar has joined #crux-devel
r0ni has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
r0ni has joined #crux-devel
r0ni has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
r0ni has joined #crux-devel
r0ni has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
r0ni has joined #crux-devel
r0ni has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
r0ni has joined #crux-devel
<farkuhar> darfo: Today I found a rare counterexample to frinnst's claim about the dangers of an in-place upgrade. Suppose you installed libbsd and libmd from 3.7 contrib, and later switched the core repo to the 3.8 branch. Your existing libbsd and libmd under /usr/opt would be left alone (unless reinstallations were forced), because the ports didn't change $version or $release when they were moved to 3.8 core.
<farkuhar> With libbsd's $version and $release left unchanged, the in-place upgrade actually became *safer* than a fresh installation on a qemu VM. Shielded by its non-standard location under /usr/opt, libbsd remains undetectable during autotools builds (unless they're told explicitly where to look), thereby avoiding the eager linking problem you reported on the mailing list.
<farkuhar> Now if libbsd had received even a bump in $release (to accompany the changed footprint and dropped README when moved to 3.8 core), then performing a sysup would have triggered the installation of the dup in core (which almost always takes precedence over the contrib collection). And then the eager linking would begin.
<darfo> Eventually libbsd will be updated again and the eager linking would begin even in that scenario.
<darfo> In-place upgrade has its place but only after study of setup-helper and review the release notes/todo.