Re: Collation version tracking for macOS

On Wed, Nov 2, 2022 at 1:42 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Tue, Nov 1, 2022 at 11:33 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> > What I'm wondering is where those ICU installations are going to come
> > from. In order for this project to be viable, we would need to convince
> > some combination of ICU maintainers, OS packagers, and PGDG packagers to
> > provide and maintain five year's worth of ICU packages (yearly releases
> > AFAICT). Is that something we are willing to get into?
>
> I hacked on this on a Debian machine that has a couple of these
> installed and they work fine, but now I realise that might have to do
> with the major upgrade history of the machine. So yeah... probably.
> :-/ Not being involved in packaging I have no idea how plausible such
> a backports (erm, forwardports?) repo would be, and I have even less
> idea for other distros.

After sleeping on it, I don't really agree that the project is not
viable even if it requires hoop-jumping to set up right now. It's a
chicken-and-egg problem, and the first step is to make it possible to
do it at all, thereby creating the demand for convenient packages. I
think we have several topics here:

1. Technical problems relating to dlopen'ing. Does it work? Is the
default dlopen() secure enough? Is it building sensible library
names, even on the freaky-library OSes (Windows, macOS, AIX)? Is it
enough to have that GUC for non-default path, should it be a search
path, should it share the existing dynamic_library_path? Are the
indirect function calls fast enough? Is the way it handles API
stability sound? Can we drop some unfinished complexity by dropping
pre-53 ICU? Does it use too much memory?
2. User experience problems relating to upgrade paths and user
interface. Is it enough to start with the basic DB2-style approach
that I've prototyped here? How should we refer to library versions?
Is your search-for-the-collversion idea better? My gut feeling is
that the early version should be about giving people options, and not
trying to be too clever/automatic with questionable semantics, and
later improvements could follow, for example if we have another go at
the per-object version tracking.
3. Library availability. This is a problem for downstream
communities to solve. For example, the people who build Windows
installers might want to start bundling the ICU versions from their
earlier releases, the people involved with each Linux/BSD distro would
hopefully figure out a good way to publish the packages from older OS
releases in one repo, and the people running managed systems probably
do their own packaging anyway, they'll figure it out. I realise that
you are involved in packaging and I am not, so we probably have
different perspectives: I get to say "and here, magic happens!" :-)

FWIW at least 57, 63 and 67 (corresponding to deb9, 10, 11) from
http://ftp.debian.org/debian/pool/main/i/icu/ can be installed with
dpkg -i on my Debian 11 machine. 52 (deb8) too, probably, but it has
dependencies I didn't look into. 71 and 72 are newer than the -dev
version (what we link against), so I didn't try installing but the
patch as posted wouldn't let me open them: the idea here is to allow
only older stuff to be dlopen'd, so if a breaking API change comes
down the pipe we'll be able to deal with it. Not being a packaging
guy, I don't how how stupid it would be to build a package repo that
literally just exposes these via an index and that's all, or whether
it's better to rebuild the ICU versions from source against modern
C/C++ runtimes etc.