5 ms·

Debian unstable follows more or less that "CI/CD" approach you're describing, but it is called unstable for a reason: sometimes, a significant change is necessa

Debian unstable follows more or less that "CI/CD" approach you're describing, but it is called unstable for a reason: sometimes, a significant change is necessary, which may lead to significant breakage as well, but most of the time, you get small breaks here and there, which are usually easy to fix (and hopefully report, so that break can be handled by the package upgrade process directly). I wonder how's Arch in that regard. You speak about breakage less common, but there has to be some significant breakage from time to time: for instance, for a shift as important as moving from traditional sys-v init scripts to systemd, it must be expected that a lot of OS configuration related packages would break, unless every package maintainer is made aware that this change would happen, and that he/she has to prepare its package (if necessary) to that shift, AND that the shift only happens when everyone's ready. But Debian (and I suspect Arch as well) do not follow such a rigid scheme, and so there has to be breakages and fixes to follow.

Tehchops 6y ago
I've encountered far more esoteric, game-breaking issues during Arch upgrades than I ever did with Debian-flavored ones.
m463 6y ago
I haven't encountered a showstopper arch break, but it might be a statistical thing. When you install arch, you install each piece on-demand. So only the pieces you have chosen are dragged through updates. my arch installations tend to be quite lightweight.
- waltpad 6y ago
  > my arch installations tend to be quite lightweight. That may explain why you don't get that many problems. If you start pulling in many different components, the set of potential interactions grows exponentially. And if you add to that external software, it easily becomes nightmarish. I've seen other comments saying that they've been running Debian or what have you for years without any upgrade hickups, and personally I've never had that. The easiest way was always to simply remove as much as possible, start the upgrade, and then pull back whatever I removed, so that the system setup would correctly fall back in to place. And even with that, I sometimes get problems. The main issue is probably not that upgrades are issue-less. The problem is perhaps the lack of cooperation between distros so that everyone could benefit from the experience others built along the way. But How does one organize that sort of cooperation? Or maybe there's too much friction between distros and upstream developers?
  - m463 6y ago
    > If you start pulling in many different components But if you've made that choice, you will likely be more aware of what you're dealing with. There are definitely valid reasons to go with big-upgrade-every-year-or-two kinds of distributions. It can make developing software that depends on other software easier, especially if you need binary compatibility. A book or article about that system won't be out-of-date immediately. Personally I wouldn't mind a few spread-out glitches throughout the year compared to frantically trying to repair a broken system after a dist-upgrade and losing a weekend. I have had a few glitches with arch, but I think they were mostly some manual intervention for signing keys and didn't harm the system.
nerdponx 6y ago
Why use Unstable instead of Testing?

Tehchops 6y ago

I've encountered far more esoteric, game-breaking issues during Arch upgrades than I ever did with Debian-flavored ones.

m463 6y ago

I haven't encountered a showstopper arch break, but it might be a statistical thing. When you install arch, you install each piece on-demand. So only the pieces you have chosen are dragged through updates. my arch installations tend to be quite lightweight.

waltpad 6y ago
> my arch installations tend to be quite lightweight. That may explain why you don't get that many problems. If you start pulling in many different components, the set of potential interactions grows exponentially. And if you add to that external software, it easily becomes nightmarish. I've seen other comments saying that they've been running Debian or what have you for years without any upgrade hickups, and personally I've never had that. The easiest way was always to simply remove as much as possible, start the upgrade, and then pull back whatever I removed, so that the system setup would correctly fall back in to place. And even with that, I sometimes get problems. The main issue is probably not that upgrades are issue-less. The problem is perhaps the lack of cooperation between distros so that everyone could benefit from the experience others built along the way. But How does one organize that sort of cooperation? Or maybe there's too much friction between distros and upstream developers?
- m463 6y ago
  > If you start pulling in many different components But if you've made that choice, you will likely be more aware of what you're dealing with. There are definitely valid reasons to go with big-upgrade-every-year-or-two kinds of distributions. It can make developing software that depends on other software easier, especially if you need binary compatibility. A book or article about that system won't be out-of-date immediately. Personally I wouldn't mind a few spread-out glitches throughout the year compared to frantically trying to repair a broken system after a dist-upgrade and losing a weekend. I have had a few glitches with arch, but I think they were mostly some manual intervention for signing keys and didn't harm the system.

nerdponx 6y ago

Why use Unstable instead of Testing?