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
Hi Alexandre,
On 2025-05-04 10:27:35 +0200, Alexandre Rossi wrote:
> 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.
>
> 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?
Cheers
--
Sebastian Ramacher
Reply to: