Hi, > > > > uwsgi.h has changed in the latest upstream, and externally built > > > > plugins need a > > > > rebuild to be aligned with this change. > > > > > > We are past the point of updates that are large or disruptive. Requiring > > > rebuilds of reverse dependencies falls into the later category. So > > > unless there is a very good reason, let's postpone this to forky. > > > > Some context: uwsgi packaging has a very naive and conservative way to > > mark API changes (md5sum uwsgi.h appended to uwsgi-abi virtual package > > name). > > These headers are only used for uwsgi plugins. This particular case[1] only > > added a new variable in uwsgi.h. > > This approach is broken for uwsgi. Note that the ABI depends on the size > of time_t and off_t. Simply running md5sum over the header does not > capture the changes in the size of these two types due to the t64 > transition.
Yes we need to come up with some better way of handling this. I'll fill a bug to document this. > > src:uwsgi is currently blocked[2] from transitionning to testing, So now we > > have > > 2 options: > > > > 1) binNMUs can be issued for uwsgi plugins, this request. I filled it > > because this is in my view low risk and will only make uwsgi plugins > > depend on the right uwsgi-abi-<md5sum> package. > > 2) We add for trixie a Provides: for that former uwsgi.h version. > > > > I would have preferred 1) to avoid carrying special lines in d/control. > > > > Can you confirm with this context 1) is still too large and disruptive for > > trixie? If so, you can close this request, we'll submit a new one when > > needed and go with 2). > > This misses the point. How does an update with 151 files changed, 2495 > insertions(+), 3114 deletions(-) qualify as small and targetted fix? This analysis misses the fact that among those changes, most were already in debian/patches. Anyway, I understand that we have missed the 2025-04-15 deadline and that rules must be enforced. Many thanks for you explainations, Alex
