[Pkg-nginx-maintainers] [Resend] [RFC] nginx packaging refactor

[Thomas Ward]

I'm just going to throw this out there:

You've asked for a refactor request on the package, for us to all review 
your work and code.  You then proceed to post an RFS **less than 24 
hours later** when there hasn't even been enough time for someone to 
review your proposal, and you skip the RC-fixing issues that are in 
1.18.0-9 in the git repository.  You also haven't suggested a merge of 
your code for review on the repository which CLEARLY is being 
maintained, so all in all this is a pretty poorly-approached request for 
comment / refactor.

You need to wait for us to review rather than just go straight to 
sponsoring requests.  I've made this same statement on your RFS bug that 
this should be NACK'd / rejected for an RFS as your changes here are 
**massive** and need a lot more review before this can be considered, 
such a large set of changes need a **lot** of time for testing, review, 
etc. before it can just be 'sponsored'.  And skipping over an RC bug fix 
in the Salsa repo with your upload is... pretty bad (FTBFS bug #1008787 
is related to the testing migration block) especially when you haven't 
even proposed a refactor/merge into the main Debian repository.

My 2 cents.


Thomas



On 4/10/22 03:02, Miao Wang wrote:
> Dear nginx maintainers,
>
> I'm a user of Debian nginx packages. I'm writing to suggest a possible way to
> improve the packaging of nginx in Debian.
>
> Currently, the nginx package is shipping several useful third-party modules.
> However, the modules are embed into the debian/modules directory and compiled
> along with the nginx binary, which has three shortcomings: 1. the version number
> of third party modules is forced to be the same with the nginx binary, although
> they have their own version numbers, and thus it is not convenient to track
> their versions. 2. An simple upgrade to any of the modules and nginx itself
> would trigger a total rebuild of the entire package, and resulting the users to
> upgrade all the packages. 3. Embedding too much code in debian/ directory does
> not look good and is somewhat o kind of abuse.
>
> The root cause of the problems is that nginx lacks the native ability to compile
> out-of-tree modules separately. However, using all the headers and the configure
> scripts in the auto/ directory, out-of-tree modules can be successfully
> compiled.
>
> Utilizing this mechanism, I created a new package called nginx-dev, containing
> all the headers and scripts needed to compile a nginx module, removed all the
> 3rd-party modules in the nginx package, and put them in separate packages.
> Additionally, I created debhelper scripts to help the packaging of nginx
> modules and improved the dn_nginx script.
>
> The module packages have their own versions now and for those the version of
> which is smaller than the current nginx, I increased the epoch. All the modules
> depends on an exact upstream version, but not a certian debian revision, because
> the signature in a module contains the version number and we can assure that
> we won't introduce abi changes to nginx during revisioning. Thus, patching nginx
> won't affect the modules and the users can upgrade only the main nginx packages.
>
> I put the above work at https://salsa.debian.org/shankerwangmiao/nginx in the
> feat-remove-mods branch, and modules also at shankerwangmiao/ngx-* in the
> deb/<ver> branch. I also included the njs module, which I'd like it to be an
> example for a complex module.
>
> It would be grateful if you have any comments on my work.
>
> Cheers,
>
> Miao Wang