At the 2013-06-26 FESCo meeting, it was requested that FPC investigate httpd-itk's use of httpd source code. Example comment from the meeting:
<mitr> Well, it's not quite obvious whether to treat this as a bundled subproject or as a fork (with forks being presumably allowed)
Please see https://fedorahosted.org/fesco/ticket/1125 for more details.
Thanks!
Proposal: Deny request to bundle apache. The potential security risk of bundling apache is high. Unless the maintainer would like to add more information that may change our mind, we'll ask fesco to block the package until apache provides the APIs needed for this package to work without bundling.
The Proposal was accepted (+1:5, 0:0, -1:0)
If you have some new reasons as to why bundling should be allowed, please add them to this ticket. We'll hold off on filing a fesco ticket to block httpd-itk until next week so you have a chance to add anything you think is relevant. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions may have some ideas for you. You can look at the meeting logs for what was discussed today: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-07-11/fpc.2013-07-11-16.02.log.html
Hello, guys. Yes, I'm five-space-tab guy and I'm ready expand tab to spaces in particular case if it may change decision.
Now seriously. I'm also hate solution to have such source doubling. And initially ask httpd maintainer provide possibility build [https://bugzilla.redhat.com/show_bug.cgi?id=597772 against present source tree]. Apache versions prior 2.4 have no API to build MPM modules and first version for Fedora 17 was packed with apache sources and patches provided by httpd package. It was follow most updates and fixes (you can see it in updates).
MPM itk nor fork nor bundling apache sources. It is standalone project provided patch (or patch set) to apache code base for version prior 2.4 because there just had no API to build modules.
Please note it is free project with acceptable license.
In your past meeting logs you are mention parallel with restriction package kernel modules. But I think it is not fully correct. We have permitted its packaging prior Fedora 9 and have guidelines as do it, but then it was banned. And [https://fedoraproject.org/wiki/Packaging:KernelModules stated in documentation]. We have no such forbiddens for apache MPMs. And decision about its inclusion in distribution can't be made solely by httpd package maintainers.
Major distributions have it already and it have major advantages for us and our users have it too. Truly speaking it is most mature apache solution for secure handle separate directories and virtualhosts under separate users. suEXEC is CGI and very slow, Worker even can't be compared, it may be compared only with [http://www.peruser.org/ Peruser] (which even official site down) and [http://httpd.apache.org/docs/2.0/mod/perchild.html Perchild] which I think single in Apache project but never been stable and marked in official documentation as not ready, Metux is threaded and so not recommended for modules like php...
So, If I make some mistake I kindly ask how I may fix it. How it should be packaged? Please say and I'll try fix it asap.
Last, even if (I'm really hope not) your decision will no changed I kindly ask do not block it. Httpd-itk package had not been built for Fedora 18 and 19. And as a last resort we can wait httpd-2.4.5 release (as all needed changes already in trunk) which will contain needed API enhancements to build against it as MPM. And I immediately do that.
P.S. What concerned about bundling libs I [https://lists.fedoraproject.org/pipermail/devel/2012-January/161271.html had asked in ML] and I understand answers what it is not related to not libs. If it is not true perhaps it need to be explicit defined in guidelines to?
Replying to [comment:4 hubbitus]:
[...]
MPM itk nor fork nor bundling apache sources. It is standalone project provided patch (or patch set) to apache code base for version prior 2.4 because there just had no API to build modules. Please note it is free project with acceptable license.
Having an acceptable license is not an issue here. The issue is exactly that it's an unofficial patch against the Apache httpd. To reiterate what I said in the meeting, the inclusion of this code in Fedora should only be done like Debian does it, i.e. as a subpackage of the httpd package. The maintainer of httpd package has spoken against it and, even ignoring that he's also one of the upstream developers, his arguments are sound. We should not be shipping code that upstream doesn't consider acceptable even for a development branch. I would argue that trying to ship code that was not accepted upstream goes against the spirit of https://fedoraproject.org/wiki/Staying_close_to_upstream_projects . The itk mpm patch doesn't fall under any of the exceptions listed there.
External kernel modules were banned for a good reason. httpd-itk is not accepted upstream and building it requires applying an unofficial patch against upstream source. This tells me the code is not ready to be included in Fedora. It was a mistake that it got through review. When httpd grows the ability to build external modules - which you say is going to happen in 2.4.5 (I haven't checked, please point to the relevant commits in upstream SVN) - then the package can be unblocked, re-reviewed and put back into Fedora.
Major distributions have it already and it have major advantages for us and our users have it too. Truly speaking it is most mature apache solution for secure handle separate directories and virtualhosts under separate users.
If it were as mature as you say then it would've been included upstream. It isn't. Other distribution's decision is their own, but they are all shipping this code as a subpackage of the main apache2 package, which reinforces my opinion that Fedora should do the same or not ship it at all.
I stated my opinion above. It should only be done in cooperation with current httpd package maintainer. This way was tried and denied (with good reasons). We would not (even if we could) force the httpd maintainer (who's been taking good care of the package so far) to apply and maintain an unofficial and untested patch (the patch for 2.4 is described as not tested even on itk upstream website) just because it might be useful to some people. Your only option is to work with him and with upstream, not around them.
If it's not working at the moment then blocking it doesn't make things worse than they already are. My suggestion is to wait until the necessary changes find their way into an official Apache HTTPD release and get build for rawhide branch. Then you can reintroduce the itk package properly.
NOTE: I speak only for myself.
The issue is exactly that it's an unofficial patch against the Apache httpd. To reiterate what I said in the meeting, the inclusion of this code in Fedora should only be done like Debian does it, i.e. as a subpackage of the httpd package. The maintainer of httpd package has spoken against it and, even ignoring that he's also one of the upstream developers, his arguments are sound. We should not be shipping code that upstream doesn't consider acceptable even for a development branch. I would argue that trying to ship code that was not accepted upstream goes against the spirit of https://fedoraproject.org/wiki/Staying_close_to_upstream_projects . The itk mpm patch doesn't fall under any of the exceptions listed there. Patch there just form of distribution, because no any other was available for past versions. Httpd-spec clearly state it in comments and other attributes like URL, summary and description.
If it will distributed as tarball with patch and bundled apache from ITK MPM page does it change something?
External kernel modules were banned for a good reason. This is present, i think it does not require talk about there. httpd-itk is not accepted upstream and building it requires applying an unofficial patch against upstream source. This tells me the code is not ready to be included in Fedora. Again, this MPM have different upstream author than Apache software foundation. We have many examples when plugins, modules distributed separately (f.e. php-pecl, ruby-gems, eclipse extensions etc.). So, there only question in form of distribution? It was a mistake that it got through review. When httpd grows the ability to build external modules - which you say is going to happen in 2.4.5 (I haven't checked, please point to the relevant commits in upstream SVN) - then the package can be unblocked, re-reviewed and put back into Fedora. I think 2.4.5 is not released yet. According to [http://www.gossamer-threads.com/lists/apache/dev/426223#426223 discussion] it is likely.
External kernel modules were banned for a good reason. This is present, i think it does not require talk about there.
httpd-itk is not accepted upstream and building it requires applying an unofficial patch against upstream source. This tells me the code is not ready to be included in Fedora. Again, this MPM have different upstream author than Apache software foundation. We have many examples when plugins, modules distributed separately (f.e. php-pecl, ruby-gems, eclipse extensions etc.). So, there only question in form of distribution?
It was a mistake that it got through review. When httpd grows the ability to build external modules - which you say is going to happen in 2.4.5 (I haven't checked, please point to the relevant commits in upstream SVN) - then the package can be unblocked, re-reviewed and put back into Fedora. I think 2.4.5 is not released yet. According to [http://www.gossamer-threads.com/lists/apache/dev/426223#426223 discussion] it is likely.
Replying to [comment:6 hubbitus]:
Patch there just form of distribution, because no any other was available for past versions. Httpd-spec clearly state it in comments and other attributes like URL, summary and description. If it will distributed as tarball with patch and bundled apache from ITK MPM page does it change something?
Patch there just form of distribution, because no any other was available for past versions. Httpd-spec clearly state it in comments and other attributes like URL, summary and description.
No, it doesn't change anything. It's still an indication that the code is not acceptable upstream (yet) and should not be shipped with Fedora.
No. I thought I was clear and wrote it a couple of times already. It would've been fine if it didn't need the whole Apache source to compile but could be built with just httpd-devel/apr-devel installed. As it is, it's a patch which was not accepted upstream (yet).
Great. Then the issue may resolve itself soon.
Again. Steinar H. Gunderson, upstream author of ITK MPM (not Apache itself) release their work under http://mpm-itk.sesse.net/. They '''is''' upstream. In market also present other MPM which may be never even proposed to be part of Apache httpd product. Have we some guidelines which clearly stated boundaries between code and lib, upstream and side project, fork and etc. And acceptance criteria for Fedora for such items? In the past was also many talks about firmware and kernel modules, now thats clearly stated after discussions and global decisions.
Great. Then the issue may resolve itself soon. Many peoples hope on it.
A few comments:
1) There is no restriction at all in the Fedora httpd 2.4 packaging to prevent packaging external MPMs. I would encourage and endorse third-party MPMs in Fedora! The problem with ITK is nothing to do with the fact that it's an MPM - it just happens to be a third-party module which requires a new API in the httpd core to work.
2) Part of the original API proposed to make ITK work, and that we were asked to patch into Fedora httpd, was rejected upstream. This vindicates our decision to not deviate from the shipped upstream core API.
3) As an upstream developer I reviewed and voted for the inclusion of the updated patch in 2.4.x. From reviewing the mail discussion we got little feedback or encouragement from anybody using ITK, so it was not 100% clear the patch was appropriate.
So due to yet another failure to engage with upstream the patches required for ITK are not in Fedora, and you'll have to wait for 2.4.7.
Login to comment on this ticket.