Bug#1104206: nmu: uwsgi-plugin-gccgo_0.0.3 uwsgi-plugin-glusterfs_0.0.3 uwsgi-plugin-java_0.0.5 uwsgi-plugin-lua_0.0.2 uwsgi-plugin-psgi_0.0.2 uwsgi-plugin-pypy_0.0.3 uwsgi-plugin-python_0.0.2 uwsgi-plugin-rados_0.0.3 uwsgi-plugin-ruby_0.0.2 uwsgi-plugin-php_0.0.15 uwsgi-plugin-luajit_0.0.8

["Alexandre Rossi" <niol@zincube.net>]

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