Re: Collation versioning

Re: Thomas Munro 2018-09-24 <CAEepm=04PvEdmRmCCcn4c7ydDA=-G=uLe5vDdfJiqp58Jpi8Kw(at)mail(dot)gmail(dot)com>
> I wonder if we would be practically constrained to using the
> distro-supplied ICU (by their policies of not allowing packages to
> ship their own copies ICU); it seems like it. I wonder which distros
> allow multiple versions of ICU to be installed. I see that Debian 9.5
> only has 57 in the default repo, but the major version is in the
> package name (what is the proper term for that kind of versioning?)
> and it doesn't declare a conflict with other versions, so that's
> promising.

The point of the put-the-version/soname-into-the-package-name business
is to allow co-installation of (mostly library) packages[*], so this
is indeed possible with the ICU package on Debian.

The bad news is that this applies to the binary package name only, the
source package (from which the binaries are built) is only called
"icu". As Debian only ships one version of a source package in a
release, there can only be one libicu$version.deb in a release.
(This means you can have libicu52.deb and libicu60.deb installed in
parallel, but after upgrading, libicu52 won't have any installation
source. You can either keep or remove the package, but not reinstall
it.)

The fix would be to include the version in the source package name as
well, like postgresql-NN and llvm-toolchain-NN. (And then find a
maintainer willing to maintain the bunch.)

Christoph

[*] now historical footnote: this wasn't the case with the
libperl-5.xx packages which conflicted with each other, which is why
upgrading Debian used to remove the postgresql-plperl-$oldmajor
version on upgrade. This has now been fixed for the stretch->buster
upgrade.