We are going to remove the hooks from the eclasses soon and for that we need all Java ebuilds to call java-pkg-2_pkg_setup. Here is the current list: betelgeuse@pena /mnt/checkouts/java/scripts $ bash check-that-eclass-function-is-called.sh java-pkg-2 pkg_setup dev-java/jdbc-jaybird/jdbc-jaybird-1.5.6.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup dev-java/jss/jss-3.4-r1.ebuild has java-pkg-2_pkg_setup overshadowed by linux-info.eclass dev-java/jusb/jusb-0.4.4-r1.ebuild has java-pkg-2_pkg_setup overshadowed by linux-info.eclass games-board/megamek/megamek-0.32.0.ebuild has java-pkg-2_pkg_setup overshadowed by games.eclass games-strategy/freecol/freecol-0.5.3.ebuild has java-pkg-2_pkg_setup overshadowed by games.eclass games-strategy/freecol/freecol-0.6.0.ebuild has java-pkg-2_pkg_setup overshadowed by games.eclass games-strategy/freecol/freecol-0.6.1.ebuild has java-pkg-2_pkg_setup overshadowed by games.eclass games-strategy/triplea/triplea-0.9.0.2.ebuild has java-pkg-2_pkg_setup overshadowed by games.eclass games-util/searchtool/searchtool-0.4.4.ebuild has java-pkg-2_pkg_setup overshadowed by games.eclass net-im/openfire/openfire-3.3.0.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup net-im/wildfire/wildfire-3.1.0.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup net-im/wildfire/wildfire-3.1.1.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup net-im/wildfire/wildfire-3.2.0_rc2.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup www-servers/resin/resin-3.0.22.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup www-servers/resin/resin-3.0.23-r1.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup
games: Can we please add java to all the ebuilds listed here so that we can fix issue with the way your ebuilds use our eclasses ourselves in the future.
net-im: Please your ebuilds to call java-pkg-2_pkg_setup in pkg_setup or ACK here and we will fix them. Will do it automatically if I don't hear from you in a week.
(In reply to comment #1) > games: Can we please add java to all the ebuilds listed here so that we can fix > issue with the way your ebuilds use our eclasses ourselves in the future. > If you mean 'Can we add pkg_setup with java-pkg-2_pkg_setup and games_pkg_setup to those ebuilds?' then yeah.
(In reply to comment #3) > > If you mean 'Can we add pkg_setup with java-pkg-2_pkg_setup and games_pkg_setup > to those ebuilds?' then yeah. > Yes that's the change we need done at this point.
www-servers/resin fixed.
You guys are free to do any change to net-im/openfire packages. The net-im/wildfire is going to be removed soon.
I did all the games stuff. Now just waiting for jdbc-jaybird (wltjr) and wildfire to get removed. betelgeuse@pena /mnt/checkouts/java/scripts $ bash check-that-eclass-function-is-called.sh java-pkg-2 pkg_setup dev-java/jdbc-jaybird/jdbc-jaybird-1.5.6.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup net-im/wildfire/wildfire-3.1.0.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup net-im/wildfire/wildfire-3.1.1.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup net-im/wildfire/wildfire-3.2.0_rc2.ebuild has it's own pkg_setup but doesn't call java-pkg-2_pkg_setup
(In reply to comment #7) > Now just waiting for jdbc-jaybird (wltjr) > > dev-java/jdbc-jaybird/jdbc-jaybird-1.5.6.ebuild has it's own pkg_setup but > doesn't call java-pkg-2_pkg_setup Took at look at ebuild to add java-pkg-2_pkg_setup. However the only reason pkg_setup exists is to force source/target to 1.2. Which is WAY old, and kinda makes my unsure about that version. If it can't be compiled as at min 1.3 or ideally 1.4. Then it's likely time I just remove that package. There are newer versions in same slot. I just kept that around for legacy purposes, but those people if still in use, can deal and move on with life.
(In reply to comment #8) > Took at look at ebuild to add java-pkg-2_pkg_setup. However the only reason > pkg_setup exists is to force source/target to 1.2. Which is WAY old, and kinda And without java-pkg-2_pkg-setup it will compile with source/target 1.6 if your system VM is set to 1.6. You think that's better? Or it will die on some unitialized variable... (I don't care to try and hopefully you neither :) don't underestimate the importance of pkg_setup pls. > makes my unsure about that version. If it can't be compiled as at min 1.3 or > ideally 1.4. Then it's likely time I just remove that package. There are newer I bet it can, just change the dep to >=1.4 and try. > versions in same slot. I just kept that around for legacy purposes, but those > people if still in use, can deal and move on with life. Sure no problem in removing all but latests version. It doesn't make sense to have more versions in one slot anyway. If people miss it, we can put it back in own slot (or in java-overlay).
(In reply to comment #9) > > And without java-pkg-2_pkg-setup it will compile with source/target 1.6 if your > system VM is set to 1.6. You think that's better? No > underestimate the importance of pkg_setup pls. I am not, just if we should modify vs remove package version. > I bet it can, just change the dep to >=1.4 and try. Going to, but pretty sure there were JDBC difference in 1.3 vs 1.4. No clue why it's set to 1.2. Legacy crud I would say, but it's doing that via gen 2 stuff. > Sure no problem in removing all but latests version. It doesn't make sense to > have more versions in one slot anyway. If people miss it, we can put it back in > own slot (or in java-overlay). Likely just punt. If they really need they can go fetch jar or etc :) Idea behind old version in same slot is so they can mask newer versions. For the most part same API and etc as far as most applications using the driver versions. Unless changes in JDBC version breaks the app or etc.
Meh, the ebuild was a early gen 2 migration, needed luv for split ant. Much less also had bundled deps and etc. I just don't feel like dealing with the older version. So I punted it, problem resolved :)
All fixed.
