[pkg-uWSGI-devel] Please give back some uwsgi-plugin-* packages

[Emilio Pozuelo Monfort]

On 04/02/2025 01:53, Adrian Bunk wrote:
> On Mon, Feb 03, 2025 at 11:11:44PM +0100, Philipp Kern wrote:
>> On 2/3/25 3:03 PM, Alexandre Rossi wrote:
>> ...
>>> For similar changes in which the binary packages names were also changed,
>>> there is no problem, they were correctly built (uwsgi-plugin-{java,ruby}
>>> and uwsgi-plugin-pypy is completely new).
>>
>> Yup, and this can never work. You need to build binary packages with a
>> version higher than what's in the archive. The archive would otherwise
>> reject it if it were to be built.
>>
>>> $ rmadison -s unstable uwsgi-plugin-gccgo
>>> uwsgi-plugin-gccgo | 0.0.2          | unstable   | source
>>> uwsgi-plugin-gccgo | 2.0.28-1+b2    | unstable   | armel, armhf, i386, riscv64, s390x
>>> uwsgi-plugin-gccgo | 2.0.28+8+0.0.2 | unstable   | amd64, arm64, mips64el, ppc64el
>>
>> So you need to either produce a binary version that's higher than
>> 2.0.28[...],
>> ...
> 
> That's what the package already does, and it is working.
> 
> The root problem is that it is fundamentally impossible to reliably
> guess the versions of the binary packages built by a source package,
> since these can be set to any value during the build and many packages
> in the archive include the versions of build dependencies into the
> versions of their binary packages.
> 
> wanna-build might not have a better option here than assuming
> binary version = source version, but that's not 100% reliable.

Why doesn't it just build the package? If it later then gets rejected, then so 
be it. It wouldn't be much different than wanna-build "rejecting" it (except for 
saving a few build cycles, but then a situation like this has already wasted a 
lot of developer cycles). I'm sure there's a good reason for the check, I 
suppose I'm just missing it...

Cheers,
Emilio