the last stable of nginx is 1.6.x and started in april 24th according to http://nginx.org/ There are ebuilds for the unstable 1.7.* in portage, but nothing for 1.6. The last 'stable nginx' ebuilds are for the old 1.4.* Reproducible: Always
As recommended by upstream: nginx-1.7.x is the mainline which should be used unless for a good reason and nginx-1.7.2 will be requested to be marked stable in ~ 1 week. If you need older versions, please use the nginx-overlay.
Oh, i didn't know. Do you have any reference about this ? The main page http://nginx.org/ still keeps pointing 1.6.x/1.4.x as "stable" as opposite to 1.7.x, 1.5.x. The later are indeed labelled 'mainline', but it's not clear that 'mainline' means 'more stable' or 'same level of stability' as "stable". If so, why call them so ?
http://nginx.com/blog/nginx-1-6-1-7-released/ "Which version should I use? In general, you should deploy the NGINX mainline branch at all times. [...] "
Tiziano Müller, to say this once more. "Which version should I use? In general, you should deploy the NGINX mainline branch at all times. [...] " Did you read the rest of it? „You may wish to use stable if you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the introduction of bugs in new features.„ Exactly this has happened to me and others, USE=rtmp has had a bug and there was only one version of nginx. This doesn't make any sense. It is relay nice to have the latest bleeding edge version of nginx. But it is no replacement for a stable version.
(In reply to andros from comment #4) > Tiziano Müller, to say this once more. > "Which version should I use? > > In general, you should deploy the NGINX mainline branch at all times. [...] > " > > Did you read the rest of it? > > „You may wish to use stable if you are concerned about possible impacts of > new features, such as incompatibility with third-party modules or the > introduction of bugs in new features.„ > > Exactly this has happened to me and others, USE=rtmp has had a bug and there > was only one version of nginx. > > This doesn't make any sense. It is relay nice to have the latest bleeding > edge version of nginx. But it is no replacement for a stable version. ..and most older branches have open security issues which other distros either manually patch or just leave open. I'm not saying this is an optimal solution (especially since bumping third party packages such as rtmp isn't always a painless experience), but it is per upstream recommendation. We - as upstream suggest - also allow you to use these through the overlay, which for these cases should be covered. Calling it "bleeding edge" is misleading since upstream calls it stable. What gentoo does best (customising builds) is in this case what ultimately makes it crumble. As mentioned in the other bug, I was waiting for rtmp to release a new version within a reasonable amount of time. That still hasn't happened, so I'll go ahead and revisit the patches today. Thanks for reading.
Johan Bergström „Calling it "bleeding edge" is misleading since upstream calls it stable.“ Maybe the description from upstream is a bit fuzzy, but it is not right that upstream calls mainline stable. I can't understand why there even is a/this discussion right now about what version of nginx should be in portage. This makes no sense to me. nginx is not just some third class application, it is an important peace of software which not has to have all the new features in it! But has to run stable! Server maintainers have to have a really stable version available. And, I'm sorry but the only stable version I see is the one that is actually called stable by upstream. It has all security fixes and is called >stable< not >mainline<. That is enough to get this one for system maintainers. As system maintainer you have to have a nginx version which you can trust by installing, which is NOT updating you in a hell of destruction. This is not an matter of >can have< this is an matter of >have to< on such an important piece software as an web server! Ok, the description on the nginx blog is a bit misleading. The mainline version has definitively not only errors in new features and changes on features/new features. It has errors in existing features that get changed! That's a fact many of us facing right now. 1.6 runs perfectly fine with USE= rtmp, 1.7.6 does not run at all! As far as I know gentoo is about choice. So why no choice on nginx? It would make perfectly sense to have both stable and mainline in portage. It does not make any sense to install an overlay for an important piece of software that is not available as stable in portage. Look at kernel.org. Mainline is the one whit all the news features/changes in it, but would you trust it to run your system with it? Don't say it is another thing, it is not. You have to trust your web server to just run!
The problem we are facing here is the nginx ecosystem itself: Whether or not the base nginx version is stable or not, third-party modules like rtmp have their own release-cycle. Therefore a stable nginx version gets "tainted" as soon as you enable a third-party module. We are already providing a huge service by including third-party modules, updating them, checking and testing them as best as we can. But unless someone really fixes this (by lets say putting together a stable distribution of nginx - similar to Tengine but maybe without the shared-module stuff) you will end up with a possibly unstable version of nginx as soon as you enable at least one external module. And we/I simply can't maintain multiple streams of nginx with different versions of third-party packages. That said: unless someone is stepping up here and taking care of the problems above, we will have to continue to concentrate on one version of nginx only and providing the older versions as best-effort only (thus maintained in an overlay).
(In reply to andros from comment #6) I totally agree with what "Andros" says. I even thought it would be kinda obvious. Andros, the answer from the official maintainer is kinda "I don't have time, and I give the development version a higher priority". There's not much we can do about it, that's the usual free software tradeoff. We can't force him to share our interests. At least we have some maintained nginx in gentoo, which is not that bad, gentoo has been leaking users and devs for years, and portage lacks more and more stuff nowadays.
(In reply to andros from comment #6) > Johan Bergström „Calling it "bleeding edge" is misleading since upstream > calls it stable.“ Maybe the description from upstream is a bit fuzzy, but it > is not right that upstream calls mainline stable. > > I can't understand why there even is a/this discussion right now about what > version of nginx should be in portage. This makes no sense to me. nginx is > not just some third class application, it is an important peace of software > which not has to have all the new features in it! But has to run stable! > Server maintainers have to have a really stable version available. And, I'm > sorry but the only stable version I see is the one that is actually called > stable by upstream. You're correct - I shouldn't have referred to it as "stable". It's mainline and nothing else. I agree that the philosophy is misleading and I also agree that calling it stable when it broke pretty much contradicts that statement. On the other hand, this is the first time we've run into a similar issue in a pretty long time. > It has all security fixes and is called >stable< not >mainline<. That is > enough to get this one for system maintainers. As system maintainer you have > to have a nginx version which you can trust by installing, which is NOT > updating you in a hell of destruction. This is not an matter of >can have< > this is an matter of >have to< on such an important piece software as an web > server! I agree that packages should "just work". Also, the fact that you loose a sense of trust since we're shipping a package with a bug is somehting I'm not very happy about as a co-maintainer. > > Ok, the description on the nginx blog is a bit misleading. The mainline > version has definitively not only errors in new features and changes on > features/new features. It has errors in existing features that get changed! > That's a fact many of us facing right now. 1.6 runs perfectly fine with USE= > rtmp, 1.7.6 does not run at all! I wouldn't call the blog misleading. The problem isn't nginx itself, it's combining it with a plethora of third party software. > > As far as I know gentoo is about choice. So why no choice on nginx? > It would make perfectly sense to have both stable and mainline in portage. I think you're somewhat bending the "gentoo is about choice" mantra to your gain here. It's rather about how you choose to compile and combine. In spirit of additional version choice we also chose to carry additional version in an overlay. I'm not saying you should go for the overlay because our gentoo-x86 tree has a bug in it -- just that we (you and I) share the same philosophy in that sense -- more versions are better but perhaps not better for everyone. > > It does not make any sense to install an overlay for an important piece of > software that is not available as stable in portage. It makes sense. Would we have this discussion if rtmp didn't break? Perhaps not. At least the rtmp bug made your opinion more obvious. > > Look at kernel.org. Mainline is the one whit all the news features/changes > in it, but would you trust it to run your system with it? Don't say it is > another thing, it is not. You have to trust your web server to just run! Before proceeding, I just want to say that I appreciate the tone of this discussion and want to thank you three for choosing your words. I understand this is frustrating and that writing what is obvious to you in such a situation could have had another pitch. My main ambition is to have a fully working nginx in gentoo that allows you to customise how it should be built. Guess you could say a perfect example of why you'd gentoo. So, with that said I think we've talked enough about philosophy. Lets focus on a solution instead. Since 1.7.x is now stable, introducing an older version (1.6.x) is a bit tricky. I haven't really done that previously or are still convinced that's what we should do, but for starters - could you try the older branches from the overlay for a while and at least attest that they're in a known state (I compile and run test but don't have them in production/staging environments). I'd also like to defer from the "time" argument. It's not about that. The fact I still haven't fixed it might be, but in a broader sense it isn't. @Tiziano: Do you have some time (I'll be online all sunday AEST) to talk on IRC? I'd like to explore our options since I agree with the bigger topic here.
