[majewsky]

I'm running Arch Linux in production for my private systems, and am currently extending it to a system previously on Debian oldstable in order to harmonize my processes.

It works very well for me (I didn't have any update-induced downtimes yet, except for the usual reboots to apply kernel upgrades), but I can easily see how people could struggle with the no-partial-upgrade problem when they employ complex, fast-moving software stacks.

My solution is to package that software myself in a private repo, so that I get to decide when to upgrade. In Arch, probably more than with any other binary distribution, it helps very much to have a good grip on the packaging process. Once you already have your private repo and signing key set up and rolled out everywhere, the barrier to rolling the next custom package is much slower.

[_yy]

> I didn't have any update-induced downtimes yet, except for the usual reboots to apply kernel upgrades

Wait until the first major backwards-incompatible config format change breaks something. Puppet was one example of many.

> My solution is to package that software myself in a private repo, so that I get to decide when to upgrade.

Works fine for single applications, breaks horribly for system-wide shared libraries.