i do not feel like reinstalling my machine, so maybe i will just write a utility to fix my apkdb

current thoughts: iterate over every path in apkdb, call realpath(2) on them, and commit that path to the apkdb instead

until apk itself is fixed to do the same, this will have to be run as a commit hook... but whatever

hmm, i guess this will probably cause problems with upgrade transactions though. ugh.

@agowa338 because the underlying filesystem layout is no longer in sync with what the apkdb thinks it is, so reinstalling the packages won't fix this, as apk records the path names in the package, not as it gets installed on disk

@ariadne

But you know on the one hand what the change that caused this drift was.

The script moving stuff.

And on the other hand you know what should be there. So when you inject new logic in a reinstall you should be able to just merge these two states, no?

@agowa338 i think it would be better to revert the /usr merge somehow

@ariadne You could do that within the reinstall thing too.

Either way you'll have to model whatever the merge script did within custom logic within apk. Otherwise I don't see how you ever would be able to merge these two states again.

@agowa338 i am now frustrated at the fact that there is no "undo option"

@ariadne There is no point in crying over spilt milk.

This entire thing however shows a flaw in pushing changes though. In enterprise we usually need to have a rollback (or exit) strategy or our change - regardless of how good or bad it is - gets declined.

@agowa338 @ariadne I think the only two reasonable ways of doing package updates are:

1. Standard “atomic” updates, via OStree, alternate primare/backup partitions, etc.
2. Use a standard package manager, but take a snapshot before it runs so that problems can be rolled back.

@alwayscurious @ariadne

1) Doesn't help fixing the issue at hand.
2) You're probably better off with #Nix which basically already does that.

@ariadne I thought about this for dpkg (though I don't really hack on that)… it probably makes more sense to explicitly special-case /usr in the client than to fix the db. It's ugly but it'll work without another pile of headaches

@agowa338 @ariadne I was replying to you about the rollback stuff.

Nix isn’t the only way to do this — snapshots at the filesystem or hypervisor level can do it as well.

i wound up rolling back usr-merge by doing the following, in case anyone else would like to:

1. apk add busybox-static apk-tools-static
2. cd /
3. cp /bin/busybox.static /
4. cp /sbin/apk.static /
5. mv usr usr.old
6. /busybox.static rm bin sbin lib
7. /busybox.static mkdir /lib && /busybox.static mv /usr.old/lib/apk /lib/apk
8. /busybox.static cat /etc/apk/world | /busybox.static grep -v usr-merge-nag | /busybox.static xargs /apk.static fix -rud
9. rm -rf /usr.old

if you do this, make sure /usr/local does not have anything important before deleting your backup of /usr :)

@alwayscurious @ariadne

Context! It was not about rolling back a package. But when you want to do a change to a software project it needs to have a plan for rolling back that change.

The change here was NOT done by the package manager. Which is the entire problem. Please try to see the context before replying to stuff...

@ariadne there is a useless use of cat in there...

What I like with apk (and alpine in general) is that as long as you have apk.static, busybox.static and /etc/apk/world you can recover from almost anything.

@ariadne you should also make sure that everything in /etc/apk/world actually exist. I had a bunch of .make* virtual packages and a python3>3.12 which messed up things for me.

@ncopa Alpine is definitely the only Linux distro that I like, the only one that came close was Slackware. But documentation is such pain in the Linux world except for one notable exception which is Arch. But then Arch is quite different from Alpine so not generally applicable.
How realistic is the creation of an Alpine Handbook? Alpine being quite minimal, this sounds not entirely impossible. Posts such as @ariadne’s should not drown in a Mastodon toot.

@pu @ariadne

you mean something like https://docs.alpinelinux.org

we need someone who can take respoinsiblity for it and maintain it

@ncopa @ariadne A mix of that and https://wiki.alpinelinux.org/wiki/Main_Page. There's no reason to have two sources of truth. I don't think this would be a one-man show; somebody needs to structure it, oversee it, suggests items to cover and keep it alive, but then also contributors.
Toots and similar would then be a link to the relevant page.

@ncopa @ariadne tbh the same is true for Arch, where you also only need busybox and pacman-static to repair the system if i.e. you upgraded glibc but not pacman itself

@ncopa @ariadne hot take: useless use of cat is a stupid concept, it makes complete sense from a mental model, just Unixy commands are stupid for being text oriented.

@pu @ncopa @ariadne is see wiki.a.o for user-curated content, and docs.a.o for thoroughly-reviewed "official" content mainly by developers

@fossdd @ncopa @ariadne I believe one coud combine both using a single source of truth. Such as having a workflow for approval of content like one does for patches. Hence having a one-stop-shop for all things related to Alpine.

@pu @ncopa the thing is, as long as you ignore the usr-merge nag script, you won't ever need that toot.

@ariadne @ncopa OTOH, having a page about all things related to usr-merge isn't a bad idea either, nor being able to search for it in a central place.
I'll stop advocating now, promised 😉

@pu @ncopa i guess my goal regarding usr-merge is that it should be incredibly *boring*

@ariadne @ncopa https://boringtechnology.club

> There's no reason to have two sources of truth.

Neither is. It's better to read issue tracker (+source code) on gitlab.a.o, sit in #alpine-* IRC channels and use wiki.archlinux.org.

@pu @ncopa @ariadne

@erindesu @ncopa @ariadne program < file doesn’t quite do the same thing as cat program | file. With the former, program can reopen /proc/self/fd/0 as writable and modify file. With the latter, it cannot. In this case it doesn’t matter though because busybox grep won’t do that.

wait how often does Alpine keep static binaries for apk and BusyBox around

@xerz "often"?
The apk-static and busybox-static packages have been there for ages but they're not in the default install, it's more for recovery and special kinds of installs.

like, if it’s always installed, then so long as you can get into a(n initramfs) shell and mount the partition where they’re on, you’re safe

…..I: might consider doing something like this on my NixOS installs, although I guess Nix is a bit more of a complex beast than apk

@ariadne

Why not just reinstall the packages (if present in local cache)?
For most systems all of the affected packages should be present within local cache. Then while doing that you'd have the information of what is supposed to be a symlink and what isn't.

(Probably hard to do in a hook and would need patching apk itself though)