On Mon, Nov 10, 2008 at 05:57:46PM +0100, Farkas Levente wrote: > currently ant-1.6.5-2jpp.2 included in rhel while ant-1.7.0 in fedora. > since even 1.7.0 is almost 2 years old (1.6.5 is more then 3 years) > there are many java packages which requires at least version 1.7. the > same problem is not apply to junit since junit 4.x called junit4, but > ant 1.7 not called ant17 like in case of automake and autoconf. > so my question is there any way to somehow include ant 1.7.x in epel? is > it possible to add a package ant17 to epel? or is it against the epel > policies? I cannot speak for the project as a whole, but if ant17 doesn't conflicts with RHEL/EPEL packages, it seems to me that it could be acceptable -- especially if you can show what a package using ant17 should use to build and select the corresponding ant and not the one from RHEL.

On Mon, Nov 10, 2008 at 09:48:13PM +0100, Thorsten Leemhuis wrote: > For ant I'm not that sure if packaging a newer version is wise or not, > as I'm not familiar enough with it. But I tend to say "that way lie > dragons", as it's hard to draw the line where to stop with it -- > otherwise we soon get request to include openoffice3 or kde4 in EPEL... I don't view it as an issue, as long as * the upgrade path is right, that is the EPEL package is updated by the corresponding RHEL/EPEL package in the next RHEL/EPEL release, which implies some coordination with RHEL/EPEL maintainers.

* the packages are stable enough for inclusing in EPEL, which is not the case for the 2 you mentionned, in my opinion, but is certainly so for ant17.

On 10.11.2008 21:57, Patrice Dumas wrote: > On Mon, Nov 10, 2008 at 09:48:13PM +0100, Thorsten Leemhuis wrote: >> For ant I'm not that sure if packaging a newer version is wise or >> not, as I'm not familiar enough with it. But I tend to say "that way >> lie dragons", as it's hard to draw the line where to stop with it >> -- otherwise we soon get request to include openoffice3 or kde4 in >> EPEL... > > I don't view it as an issue, as long as * the upgrade path is right, > that is the EPEL package is updated by the corresponding RHEL/EPEL > package in the next RHEL/EPEL release, which implies some > coordination with RHEL/EPEL maintainers. Well, such coordination in the EPEL past afaics often didn't work that well (just like it didn't in the Extras days when Extras maintainers had to deal with maintainers from Fedora Core). > * the packages are stable enough for inclusing in EPEL, which is not > the case for the 2 you mentionned, in my opinion, but is certainly > so for ant17. Well, the 2 I mentioned were (obviously) extreme examples. But as I said: where draw the line/where stop? People likely have good reasons for hundred other packages that are basically new versions of software that is already included in RHEL. I fear that the whole things could get quite messy over time.