Re: Plans for forky
On 12/13/25 5:23 PM, Antonio Valentino wrote:
Dear Sebastiaan, dear Francesco, dear all,
I would like to share with you my plans for new packages that I would like to add to debian-gis during the forky cycle.
I do it before starting the actual job and before filing ITPs to have a chance to have a discussion, if needed, and to get feedback from you.
My first thought seeing the list of packages, is that you need to recruit more people to help maintain these packages.
Do you have any colleagues you could tap into for manpower?
Please consider that I plan to maintain the packages myself, but as a DM, I could need some help, from time to time, from a DD.
For sure I will need support for the first upload.
From my perspective nothing will change, I'll create the repos on Salsa, sponsor the NEW uploads, and grant DM permissions on these packages.
As long as truck-kun is not coming for me.
The fist group of packages that I plan to include is mostly a collection of (optional) dependencies of packages that are already in debian-gis:
* s3fs: https://github.com/fsspec/s3fs (needed by satpy, stac-asset and zarr)
* universal-pathlib: https://github.com/fsspec/universal_pathlib (needed by zarr and satpy)
* google-crc32c: https://pypi.org/project/google-crc32c (needed by zarr)
* cql2: https://github.com/developmentseed/cql2-rs (needed by pystac-client)
* stac-pydantic: https://github.com/stac-utils/stac-pydantic (needed by stac-validator and stac-check)
* obstore: https://github.com/developmentseed/obstore (needed by zarr)
Makes sense to start with these.
Please note that some of them are written in RUST, but I still think that it is a good idea to have them in debian-gis.
Dependencies for geospatial packages already maintained in the team remain welcome.
I have zero experience with rust packages, so can't really add any value there.
Pure Rust packages are likely better maintained within the Rust team according to their standards with their cargo based tooling, etc.
The only exception could be obstore. It is a general purpose package providing access to S3, so, maybe, it could make sense to have it in the python or rust teams.
The python-deprecated is quite similar, it's maintained in the GIS team because it's a dependency of one of our packages, that's fine as mentioned before.
If you'd rather maintain it one of the other teams that's fine too, I'm unlikely to object to less work.
I would really appreciate any comment / suggestion, especially if you think that some of the listed packages are not relevant enough to be include din Debian.
I assume you're maintaining these packages because you use them yourself on your Debian based systems.
If you're maintaining these packages for the sake of someone else who didn't explicitly ask for them via RFPs, then I suggests to reevaluate your priorities.
You're doing great work on the remote sensing packages, it would be a big loss if you burn out by an overwhelming workload.
Please feel free to add to the list package that could be related to the one indicated bu not included in the list.
I already maintain too many packages I don't actually use myself, I'm unlikely to be adding any packages.
Package removals are much more likely during the forky cycle. libkml, osm-gps-map, php-geos, and pktools are dead upstream for example.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: