Conversation
Notices
-
Embed this notice
@phrawzty I guess I'd nominate those, in no particular order: Devuan, Slackware, Gentoo, Alpine, Chimera
(Personally on Gentoo and Alpine)
-
Embed this notice
@phnt @phrawzty Right Artix too, in fact used it for a bit because Arch chroot on a non-systemd system seemed a bit broken.
And then pacman screwed up, just Arch things. :D
-
Embed this notice
@lanodan @phrawzty I've migrated my Arch install to Artix OpenRC couple months ago and honestly I can't complain at all. Everything that isn't already broken upstream of Arch works perfectly.
-
Embed this notice
@Tadano @phnt @phrawzty Oh that reminds me: Void Linux.
And I think it's better to use a distro where the service-manager and related is well supported, so lightweight forks might not be the best way. But that's mostly just an opinion, kind of hard to actually compare how reliable things are.
-
Embed this notice
@phnt @phrawzty @lanodan Egh in my experience I've had weird shit and slow repos on Artix runit. As cool as that init is I've resigned regarding the systemd question.
-
Embed this notice
@phnt @phrawzty I mean I've been using and contributing to Gentoo since at least 2016, I'm fine with things being manual, in fact I'd rather have things be manual than automatically have them do something potentially wrong.
What I don't like is brittle tools, specially system ones, and pacman is just that.
-
Embed this notice
@lanodan @phrawzty I've seen pacman break a few times when using AUR helpers, that's fair.
With Arch there's always some manual assembly required. Which to some extent is a good thing if you want to learn about how the whole Linux ecosystem works under the hood, but I understand it can be annoying.
-
Embed this notice
@phnt And by brittle I mean that a rather normal workflow shouldn't include having to do some kind of recovery.
Package fails to update or add a new package but system continues to work? 100% fine to me, could just report the issue and wait for a fix.
Package manager fails to update the signing keys? Urgh, this shouldn't happen.
Lack of library management so you can end up with pacman libraries being missing? Then why is there a package manager in the first place if not to manage dependencies and so avoid this kind of case.
-
Embed this notice
@phnt Yeah AUR helpers I could understand them breaking and I consider that to be okay-ish, kind of which arch would have better support for community repos but well it's their choice.
ctrl-c pretty sure I never did, it's never a good idea, I do it on Gentoo sometimes but only when I know I could easily recover (and gentoo uses files instead of a database so less possible corruption).
> Which is a common problem if the system is left sitting for a month or two without updates.
I guess that's side-effect of how OpenPGP expires keys all to similarly as if they got revoked, ultimately making it hard to do slow key-rotation without ending up with keys valid for easily more than a year…
For packages I quite prefer the idea of rotating keys regularly and having some kind of limit placed on them not being system time but rather contextual time, like how OpenBSD uses a key per release (so roughly every 6 months), with the key of the next release being part of the release so sneaking an arbitrary next key seems pretty hard.
-
Embed this notice
@lanodan
>Lack of library management so you can end up with pacman libraries being missing?
That shouldn't normally happen. The library pacman uses to do most of the work (libalpm) is owned by the pacman package. I've seen AUR helpers break when used as "system updaters", because they aren't rebuilt against the new version of the library and the linker properly throws it's hands up when the helper tries to launch itself again and can't find the proper version shared library.
I've never seen it fail this spectacularly and the only cause I can think of is that it only partially extracted the new pacman package or one of the dependencies (lack of free space, power outage, killed by user/system).
Btw sending ctrl-c when pacman is running any kind of package transaction (include pre/post hooks) is the fastest way to innocently kill an Arch system. The internal package database isn't updated properly, which will lead to pacman confusing package versions and your initcpio very likely missing.
>Package manager fails to update the signing keys? Urgh, this shouldn't happen.
I've seen this happen only when it couldn't verify the signature of the new keyring package based on the old keys it had. Which is a common problem if the system is left sitting for a month or two without updates. And probably the reason why pacman doesn't enforce signatures for local package installs.
Haelwenn /элвэн/ :triskell:
Phantasm
Tadano
All GNU social JP content and data are available under the