I nearly bricked my laptop running main due to this entry today since it deleted libwind.so.11 needed by libcurl.so.4 and thus git (so I had no working git binary until I obtained a copy from another machine).

My reasoning here is that we use OLD_LIBS for pam, etc. plugins as well.

Curiously in the clause above this for MK_TESTS==no, these entries are correct. These might also be missing the .2 versions in the earlier clause?

this is not a library, this is the run-time linker

I believe this is intentional as libatf was never meant to be public, it's a private library now

I think that's reasonable, even if these plugins don't really need to be handled as LIBS.

sorry about that. for consistency, please move this entry to live with the other OLD_LIBS entries at the end of this block (line 3618).

i believe we do this for PAM modules because we provide 32-bit versions in /usr/lib32, and using OLD_LIBS takes care of those automatically. since there are no 32-bit KDC plugins, we don't need that here.

however i don't feel very strongly about this one way or the other.

Fair point. Maybe we should have a comment on the PAM entries referencing this.

I think the point is should these be deferred to make delete-old-libs or not. That is, if 'lib<mumble>.so.122' is going to dlopen() these specific files, then they are dependencies of lib<mumble>.so.122 and shouldn't be deleted until lib<mumble>.so.122 is deleted. In that case, they need to be in OLD_LIBS just like the lib<mumble>.so.122 that depends on them.

Yes, I specifically called it out in the commit log. It makes no sense to delete the runtime loader with OLD_FILES but still leave the shared libraries around via OLD_LIBS as you can't use those shared libraries without having the runtime loader. That is, if I do make delete-old WITHOUT_LIB32=yes today it will delete ld-elf32.so.1, but leave /usr/lib32/lib*.so.*, but without a way to make use of those libraries. In that regard, rtld is a kind of shared library (it's even built as PIC, etc.)

Well, but if you look at this block of code, it's really odd. It's roughly:

.if ${MK_TESTS} == "yes"
# delete various files
.else
# delete many of the same files, but not exactly the same
.endif

This is in the else clause. The if clause uses OLD_LIBS and also lists usr/lib/libatf-c++.so.2. Arguably, the files listed in both places aren't conditional at all and are just truly-old files that should be in src/Obsoletefiles.inc. That is certainly true for /usr/lib/libatf* which became private over a decade ago (2014). The SHLIB_MAJOR bump from 1 to 2 for libatf-c++.so was also in 2014 so clearly the .1 versions should just be OLD_LIBS in src/Obsoletefiles.inc. However, there are several other duplicates in the two clauses that should also probably move. I kind of gave up on trying to understand / fix this as the logic is rather confusing and not at all clear.

i believe these can only be loaded by /usr/libexec/krb5kdc, which is in OLD_FILES, so i would lean on the side of deleting the plugins along with the KDC binary since nothing else uses them.

@cy is the person to ask about this though.

That would be a good reason for OLD_FILES, yes. It depends on what dlopens them. For pam modules it is libpam, so that is the reason for using OLD_LIBS rather than lib32, though the library loading is also why you end up with lib32 versions (so the two are correlated).

There's another aspect here, does krb5kdc know about versioning? libpam does and will look for pam_foo.so.N before pam_foo.so, but that's not standard practice. If krb5kdc doesn't know about versioning, then the symlink also needs to be in OLD_LIBS, because krb5kdc will never find the versioned plugins without the unversioned symlink. The bottom line is that OLD_LIBS wasn't really designed with plugins in mind and may not dtrt.

btw the obsolete.sh script I started working on a while back moves libraries to a backup directory instead of deleting them.