Re: Plans for forky
Dear Bas,
Il 13/12/25 18:09, Sebastiaan Couwenberg ha scritto:
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?
Unfortunately no for the time being, but who known in the future :)
As I said I will do only the things that I manage to do in my limited
time. It is perfectly possible that some of the packages in the list
remain there (maybe for the next cycle).
E.g. in the past cycle I had some plans for ESA SNAP
(https://step.esa.int) but it is still in the list and not top priority
at the moment.
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.
thanks a lot
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.
yes, I agree
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.
thanks
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.
OK, understood
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.
ok :)
I still need to look more deeply into it.
cheers
--
Antonio Valentino
Reply to: