do not run the #alpinelinux merge-usr script if you want `apk info -W <file>` to keep working properly

to be clear: i think /usr-merge is good for alpine, but i also think this is an area where the TSC approved it without collecting input from all stakeholders, which resulted in bad planning / success criteria.

these process failures continue to hurt alpine

@ariadne I'm imagining this with the peter griffin running meme

@ariadne dpkg -S is equally broken, for presumably the same reasons 🤪

@equinox wonderful

@ariadne wait, is it broken on all merged installs, or just migrated merge installs

@justsoup @ariadne

There are many packages which access files through /bin, /lib or /sbin. It would break these packages. Patching the packages is not really viable due to needing many patches and we can't really determine which packages need to be changed.

@justsoup @ariadne

But there are also good reasons for moving things one by one. As far as I can tell /bin, /lib and /sbin are meant to be deprecated/compat which indicates the intend to remove them eventually. By creating compat symlinks for the entire /bin, /lib and /sbin directories we know less which files are accessd that way which contradicts with considering the deprecated. So people who want an atomic /usr should want distros to be non-/usr-merged and push moving of files inside of the "deprecated" packages one by one with compat symlinks which can be scheduled for removal in a sensible time frame.

@sertonix @ariadne It's really a "have your cake and eat it too" kind of problem. You can merge /usr, removing the issue of the raw root directories existing, but then you just mask the issue. Yet, if you push off merging /usr, you are stuck with the raw root directories and all the headaches that they can cause. I've always been a fan of the more gradual approach, but I also understand some users just want it "done already", so the merge-usr script is a happy medium I think.

@justsoup @ariadne

> if you push off merging /usr, you are stuck with the raw root directories and all the headaches that they can cause

Other than /bin/sh there isn't really anything that can't be moved completely in alpine.

@sertonix @justsoup earlier, you say it is difficult due to lack of resources though.

personally, i care a lot about my package manager state actually reflecting the installed system.

that the TSC has approved this proposal without considering the integrity of the apkdb is, frankly, frustrating to me.

i am going to have to reinstall my workstation in order to fix the incongruencies with my apkdb, and frankly it leaves me pondering whether it is time for me to just move on from alpine.

this isn’t anyone’s fault but the TSC, as they approved this proposal without considering input from the apk maintainers, who would presumably have pointed out that the merge-usr script needs to fix the apkdb, or that another approach should be taken. blaming the TSC does not fix my apkdb though.

i use alpine because at least until recent iterations there has been a culture of precision in how large system changes are engineered. i worry we have lost this culture, and i have already decided at a minimum that i won’t be deploying v3.23 in production anywhere. i simply don’t have confidence in the release.

@wouter @kouhai alpine is broken in the same way, as dpkg’s state and apk’s state are basically stored in the same way.

@justsoup @sertonix to be clear: i have no objection to the script itself, my objection is with the apkdb being broken.

@sertonix @justsoup @ariadne Have been tried by SUSE, didn't work. Was proposed for Debian as well by people. Why do you think it would work for Alpine?

@sertonix @justsoup @ariadne You don't have fixed locations for dynamic linkers outside of /usr?

@waldi @sertonix @justsoup we do. the dynamic linker lives in /lib, just as with a glibc system.

@ariadne @sertonix @justsoup Just to get the expectation straight: was there a proposal by the apk maintainers on how to handle this? The situation sounds much like Debian several years ago, where the project made that decision against the dpkg maintainer.

@waldi @sertonix @justsoup the apk maintainer did not provide input either way during the time window that the TSC discussed the proposal. i do think the apk maintainer should have been engaged in the conversation, but alas he was not.

@ariadne @waldi @sertonix @justsoup he is now for sure

@ncopa @waldi @sertonix @justsoup yes. he is now involved. i wish that he had been involved before merge-usr broke my apkdb, or the apkdbs of other people who have reported regressions far more severe than what i've observed...

@ariadne @sertonix @justsoup

If you don't have confidence in the v3.23 release then that's basically a death sentence for that release.

@agowa338 @sertonix @justsoup

I honestly think the only way forward is to rip out this usr-merge stuff and try again.

Otherwise people are going to upgrade, then the usr-merge-nag commit hook will tell them to run this merge-usr script, which will break their apkdb moving forward.

Again, I have no objections to merged /usr in theory, but I do have objections to breaking state that is used to measure system integrity.

@ariadne @sertonix @justsoup

Tbh I'm on the beleading edge version of alpine and when I saw the usr-merge-nag I was like "why did they not do that in packaging?" followed by an (in hindsight good) "I don't have time for that. If it was important it wouldn't even ask me about it *ignore*" :p

@agowa338 @sertonix @justsoup just `apk add !usr-merge-nag` and continue with life

@ariadne so if I understood it right, alpine's usr-merge was implemented by putting the /bin symlinks in place but *not* rebuilding all the packages to match? so stuff still gets unpacked to /bin/foo, and the package manager still tracks it as being /bin/foo even though it's physically at /usr/bin/foo?

(I don't remember anymore how it was done on Arch, I just have vague memories of "this is too annoying I'll just move everything to /usr manually and `sed` the database accordingly"... nowadays pacman refuses to install across a symlink so packages *have* to put files in /usr, and 'pacman -Qo /bin/foo' does a realpath on the queried file)

@grawity correct

@lanodan @khm thankfully, 3.23 will no longer tell people to run this experiment by default, and we can work to make the /usr merge actually safe.

@justsoup @sertonix i agree that is the best path forward. but there are things we can do in apk to make changing the layout safe.