Bug 1150393

Note that I plan to support this package only in F21+, because of nginx-filesystem dependency.

rpmlint tengine-*
tengine.x86_64: W: non-standard-uid /var/log/nginx nginx
tengine.x86_64: W: non-standard-gid /var/log/nginx nginx
tengine.x86_64: E: non-standard-dir-perm /var/log/nginx 0700L
tengine.x86_64: W: non-standard-uid /var/lib/nginx nginx
tengine.x86_64: W: non-standard-gid /var/lib/nginx nginx
tengine.x86_64: E: non-standard-dir-perm /var/lib/nginx 0700L
tengine.x86_64: W: non-standard-uid /var/lib/nginx/tmp nginx
tengine.x86_64: W: non-standard-gid /var/lib/nginx/tmp nginx
tengine.x86_64: E: non-standard-dir-perm /var/lib/nginx/tmp 0700L
Could you comment on permissions? I know servers have a little unusual settings.
tengine.x86_64: W: dangerous-command-in-%post chmod
I agree chmod should be done in the install section.
tengine-devel.x86_64: W: no-documentation
tengine-devel.x86_64: W: no-manual-page-for-binary dso_tool
Could you create at least one man-page, which would tell at least some information?

Does the nginx code is copied or copied and modified? It seems to me in core/src. I guess you will need an exception and add Provides: bundled(nginx) for tracking of possible CVEs.
More comments will follow...

Tengine is fork of nginx. The nginx code is patched heavily to bring new features. Upstream merges changes done by nginx upstream into Tengine when new nginx version is released.

It's the same situation as for MySQL vs. MariaDB. I don't see any bundling exception for MySQL vs. MariaDB.

But still it's questionable. I know why you need it, but it's ugly :-/

Other sources like 404.html 50x.html contains Powered by nginx. Shouldn't it be powered by Tengine?
tengine.init contains nginx.conf and calling of nginx, which is probably fine, because Fedora will be using tengine.service. Personally, I dislike calling binary nginx. There is set a strict conflict with nginx, so it should be functionally fine.

Only man page is called nginx, which doesn't seem right. At least you should create link from tengine man page to this nginx.

You are missing check section in specfile. Did you think about running tests during build time? At least some? They could be conditionalized for running on local if it's not possible to run them at koji.

(In reply to Marcela Mašláňová from comment #6)
> Other sources like 404.html 50x.html contains Powered by nginx. Shouldn't it
> be powered by Tengine?

Yes, I overlooked that, I'll fix that in next SRPM.

> tengine.init contains nginx.conf and calling of nginx, which is probably
> fine, because Fedora will be using tengine.service. Personally, I dislike
> calling binary nginx. There is set a strict conflict with nginx, so it
> should be functionally fine.

I must admit calling the binary differently would be better, but it's upstream decision to stay binary compatible even when it comes to binary name (so you can replace nginx with tengine without even rewriting the initscript and so on).

(In reply to Marcela Mašláňová from comment #6)
> Only man page is called nginx, which doesn't seem right. At least you should
> create link from tengine man page to this nginx.

I will create man-page for "dso_tool" and "tengine" link to "nginx".

> You are missing check section in specfile. Did you think about running tests
> during build time? At least some? They could be conditionalized for running on
> local if it's not possible to run them at koji.

The problem with "make test" is that currently it needs tengine to be installed to test it. That's not possible to do during RPM creation. I will try to find out how to persuade that test-framework to test tengine without installing it, but if I won't success, I will have to follow the way used by nginx package maintainer - do not run make test during compilation.

Spec URL: http://jkaluza.fedorapeople.org/tengine-2.0.3-2.fc22.src.rpm
SRPM URL: http://jkaluza.fedorapeople.org/tengine.spec

You may need to revise the package since this package shares the same source code from nginx.

(In reply to Christopher Meng from comment #10)
> You may need to revise the package since this package shares the same source
> code from nginx.

As I already stated in description of this review, Tengine is fork of nginx keeping the binary compatibility with nginx, but bringing more features. It's therefore clear the source code will be shared. It's the same situation as with mysql vs. mariadb.

I would like to see tengine in EPEL and I can become reviewer (and co-maintainer for EPEL branches) because you don't need sponsorship but I see a reason that could prevent tengine from joining Fedora package collection:

According to packaging guidelines for conflicts [1] you should contact Fedora Packaging Committee [2] because tengine may be considered as a drop-in replacement for nginx but not vice versa and this case isn't described properly in packaging guidelines.

I think that you could use alternatives [3] for tengine and this will be the best solution but this decision is not in my responsibility.

Could you contact Fedora Packaging Committee?

[1] https://fedoraproject.org/wiki/Packaging:Conflicts#Other_Uses_of_Conflicts:
[2] https://fedoraproject.org/wiki/Packaging_Committee
[3] https://fedoraproject.org/wiki/Packaging:Alternatives

Any progress on this?

@Jan Kaluža: Are you still interested in packaging Tangine? If yes please provide a refreshed SPEC so I can continue the review.

Tengine builds now freely available via third-party GetPageSpeed repository: https://nginx-extras.getpagespeed.com/tengine/