Andrew C Aitchison <[email protected]> writes: > On Thu, 5 Feb 2026, Greg Troxel via gdal-dev wrote: > >> Andrew C Aitchison via gdal-dev <[email protected]> writes: > > There are newer package types like snap and flatpak which are supposed > to be flavour-agnostic (snap seems to be Debian and Ubuntu-only) > and allow *users* to install them without being root (typically using > a container to isolate the machine from the application).
FWIW pkgsrc can be run as a user as long as you bootstrap it to a prefix you can write. I used to use $HOME/pkg on a Debian system where I didn't have root. >> For micro releases, I suspect you can just do this and then run qgis, >> checking with ldd to see what it links with. >> >> For non-micro, you would then want to get the control files for qgis and >> then build/replace a package. > > Current Ubuntu (Questing, 25-10) comes with gdal 3.10.3 and qgis 3.40.5. That seems surprisingly out of date at first glance, but I guess that's only from April of 2025. > I like to keep several versions around so that I can check for > regressions and other changed behaviour. > For example if I find a problem whilst testing the GDAL 3.12.2 release > candidate, it is useful to be clear whether the problem was present > in say 3.11.x, 3.12.0 or 3.12.1. > > As you say qgis can be made to use a different/newer micro release, > but I was hoping you had found a way around needing to rebuild qgis for > each mini-release of gdal. I don't think there is a way. I use ccache, and I find that it doesn't really take all that long. I think you're heading down a path where you want the cross product of qgis and gdal versions, and that just is n*m. Personally, and with pkgsrc hat on, I don't pay attention to releases older than what pkgsrc has, and I try to keep pkgsrc updated to the most recent release that feels responible to update to. GDAL has been very stable with no significant issues introduced in minor releases, so while I do verify that my qgis project opens and shows data, I don't worry much. Sounds like you are testing what you need to. I find the "one is installed in the system at any given time" approach to help sanity, and if I wanted to check old gdal I'd just checkout the gdal pkgsrc bits for the old version, make replace, and then rebuild depending packages. But so far I have been able to avoid caring about older versions. _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
