Yes, I know there might be checksums, but I think it's still a problem.
As you've noticed by carefully reviewing the PR 😜 , it uses sha1sum to
identify tags
I think a good example is librsvg. It's a library, written significantl
in rust, but programs that use it just look for a .h and link against
it. They aren't forced to act like it's all special because it used
rust.
As you've noticed, my PR offers that possibility if someone packages
cpcodec and installs pcodec.h and libpcodec.so
Is pcodec packaged in Debian or any place else?
Not that I'm aware of
Deoes gdal have a prior history of dealing with dependencies that should
be packaged but aren't?
yes and no. We have a few vendored ones
I wonder if the plugin system is the answer here, to say that anything
with troublesome (not packaged and checkable with cmake without special
help) dependencies should be a plugin maintained in a separate repo.
The Zarr driver itself can be built as a plugin. But a plugin of a
plugin, that's unknown territory
Anyway if you or anyone else doesn't like it, GDAL_USE_PCODEC=NO will be
your friend, and/or not having git or cargo in your build env.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
