How do rolling upgrades work in a binary distro?

[hazel]

I can understand continuous rolling upgrades in Gentoo because everything is compiled in situ; if a library undergoes a major upgrade, packages dependent on it can simply be recompiled. But how do binary distributions like Arch and Debian Sid handle this kind of situation?

I can see how minor library changes could be handled automatically by the symbolic links in /lib and /usr/lib; programs are built against the symbolic link, and that links them to the current version of the real library. But what about changes to libraries that might make a program behave differently - or not find a particular called function at all?

[Irithori]

If you take CentOS/RedHat as an example:
They have a major version every X years, and minor versions inbetween.

Major versions have new features, new libraries, new apps.
Minor versions are more or less in feature freeze mode:
- only bugfixes
- done by backports, if neccessary.

That´s why CentOS/RedHat still have (for example) apache 2.2.3 or php 5.1.6

The good part about that is:
You can do (security)updates with relative ease.
It is 99.9% certain, your applications will behave exactly like before and you have an updated system.


And yes, I used to have gentoo.
The flexibility and of course documentation is great.
I even installed a few servers with it.
But in the end and to my taste it required too much babysitting.

[hazel]

If you take CentOS/RedHat as an example:
They have a major version every X years, and minor versions inbetween.

Yes, that's the traditional way of doing it. Each new release probably contains a new kernel and a new glibc - and maybe a switch from GRUB to GRUB2. But there are distros nowadays that have rolling releases, like the two I named. They never have a major upgrade. So how do they deal with new major versions of important libraries?

[elija]

I would guess that the packages that depend on the library are rebuilt and rolled out as updates.