You are not logged in.
Regarding this, which happened roughly a month ago. https://www.archlinux.org/news/js52-527 … ervention/
Just a few humble requests for some information regarding what happened here. I've tried researching what a soname is and how ldconfig works, but I'm definitely still missing some things.
Specifically, I don't understand why this very simple file operation wasn't able to just be incorporated into all the other processes that happen during a standard system upgrade? Is this something not worth investigating at my level of understanding? It's funny how the more I learn about arch and pacman, the more I realize I basically know nothing except what all the devs and wizards tell me to do. I feel like I'm constantly just trusting in the probity of much more advanced users lol. My goal is to one day, be enough of a power user to slightly understand what I'm actually doing half the time I'm fixing my machine haha
I'm honestly not even much of a newbie. I've been using arch consistently for upwards of 3 years now and obviously I still feel like a newbie. At this point, I'm pretty confident I'll never grow out of the neophyte stage, but a man can dream, right?
As prep for the kind folks that'll just tell me to do my own research, I've already looked into the following:
https://bugs.archlinux.org/task/58459
https://www.reddit.com/r/archlinux/comm … _requires/
In both links, it's stated in one way or another that the news announcement was the only solution, but I'm still not experienced enough to understand their reasoning.
'The conflict resolution is done before the install hooks are run, so we can't include anything saying pre_install(){ rm -rf /some/file;} as pacman doesn't get that far.'
-This actually makes the most sense to me, but I still don't understand what he means by "pacman doesn't get that far." Before pacman starts any of the upgrade process, couldn't it just check if the file was there and remove it if it is?
Offline
dynamic linker and shared object, name
probably doesn't answer your question about js52, but there actually is a lot of info out there on ld and so... there is also a good reason why pacman doesn't remove those files, but that was 5yrs ago and i forget.
---8yr linux neophyte
∞ hard times make the strong, the strong make good times, good times make the weak, the weak make hard times ∞
Offline
The problem at hand really doesn't have much to do with soname or shared objects and how they work in particular. The issue simply happened because the symlink to the final library, which is usually part of the package, has accidentally not been part of the package and was generated by ldconfig. Pacman will, by design, not touch a file that it doesn't know about (unless using --force, or much better, the newly introduced --overwrite option). Let's assume it wasn't an "unimportant" library symlink being touched there. But for some reason you decided to have a important family foto at /usr/lib/libmozjs-52.so.0 for some reason.
You wouldn't want pacman to simply remove that just because "it's supposed to be a library file I know about". That's why pacman will stop there. The relation of soname bumps an ldconfig really has only a tangential relevance as to why pacman refuses to proceed.
Offline