Re: [courier-users] Ubuntu and Courier upgrade

[Matus U. - f. <uh...@fa...>]

>>>I don't have a working Ubuntu server at the moment, but I did have 
>>>one last year, and I updated it from 20 to 22. I don't have a lot 
>>>of confidence in Ubuntu's upgrade process. It apparently starts 
>>>with the currently running system, live, just like that, then 
>>>installs all updated packages, one by one, then reboots.

>Matus UHLAR - fantomas writes:
>>I have perfect experience with upgrading multiple debian servers 
>>through multiple veersions of debian. Debian packages are required 
>>to be upgradable from previous Debian versions and this rarely 
>>breaks with stable Debian.

On 23.02.23 19:33, Sam Varshavchik wrote:
>It's easy to state that Debian packages are required to be 
>live-upgradable. But a policy statement, and the practical reality can 
>sometimes be two completely different things, in practice.
>
>When you're talking about simple, basic packages – a couple of shell 
>scripts, or standalone executables, no complex dependencies, maybe a 
>few man pages – this is not complicated. dpkg will take care of 
>installing the new files, remove any files that are no longer a part 
>of the package, and the running executable will chug along until the 
>shutdown script SIGTERMs it, and it cleans itself up gracefully.
>
>But when you get involving in complex system libraries and demons the 
>situation quickly becomes not as clear-cut. I really don't want to be 
>running do_release_upgrade when it replaces glibc and libstdc++ with a 
>binary-incompatible version, and there's a bunch of stuff running 
>that's dependent on a specific libstdc++ ABI.

Exactly this problem is avoided by having different packages with different 
ABI, e.g. libstdc++5 and libstdc++6.

If the ABI changes, your package depends on older library version and will 
use the old libraty. Restarting won't change anything here.

In the meantime, you can have packages depending on different library 
versions installed in parallel. Proper Depends: and Breaks: statements 
handle this.

>The only guaranteed way to update to a new ABI is to uninstall 
>everything that depends on the old ABI, install the new ABI, remove 
>the old ABI, then install the new versions of all removed packages 
>that were built against the new ABI. Most packages are not going to 
>restart the binaries, and cut over to the new ones, until all of that 
>is done. Until then, the running packages' binaries are skating on 
>thin ice. They're still running with the old shared libraries loaded, 
>but everything on disk's been updated.

>And now, here comes Courier, whose main demon periodically restart 
>itself, when it's idle. If it happens to pick just the right moment to 
>restart itself, when either Courier or libstdc++ has already been 
>updated, but libstdc++ not, or vice-versa, then the end results cannot 
>be reliably guaranteed. Forget about the parent process still running 
>the previous version of Courier, and attempting to restart the child 
>daemon from the newer version, the entire restart has its warranty 
>voided, due to a likely libstdc++ ABI break.
>
>When you have a distribution package that's prepared and maintained by 
>the same entity who maintains the upstream package, and is intimately 
>familiar with all of its internal gears, and how it works, perhaps in 
>that case one might have some reasonable expectations of compliance 
>with the policy of uninterrupted updates. But that's not my impression 
>of how most packages get maintained, which is by third party 
>developers. They may be have very good general knowledge of what 
>they're doing, but I don't know how likely it is that they'll have 
>sufficient, in-depth knowledge of complex packages and their intricate 
>dependencies, to guarantee an interrupt-free live update.

This may be a problem for Fedora or rolling distributions, where packages 
are to be rebuilt once in a while (e.g. gentoo)

Yes, things can get broken, but I don't remember encountering this for years 
and for multiple upgrades. It's just the opposite.


Yes, if you want to be safe, you can upgrade in single user.
Yes, you can reinstall.
But you rarely have. 


OS I write this on was installed in 2003, migrated (=copy fileystem) between 
HW a few times.

My home machine was installed in 1998, migrated a few times and the only 
case it was "broken" was when I migrated from i386 to amd64.
(yes, you can do that in Debian).

I even turned the machine off in the middle of upgrade (ofcourse, not during 
package installing, but between) and continued next day, without problem.



This is why I asked OP, where did they get the strange courier versions.
The upgrade should be OK, unless someone build own packages, possibly 
broken.

But that's either something Ubuntu supports (if those are ubuntu packages), 
or something nobody can support.

-- 
Matus UHLAR - fantomas, uh...@fa... ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759