On Wed, Nov 2, 2022 at 1:42 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Tue, Nov 1, 2022 at 11:33 PM Peter Eisentraut > <peter.eisentr...@enterprisedb.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.