Hello! This eclass depends on sys-apps/portage. Is this needed? Maybe virtual/portage would suffice and it would help in adoption of other package managers. There is already opened related bug. I marked it as blocked one.
The reason: https://forums.gentoo.org/viewtopic.php?p=3415514 And the reason we have this dep in java-pkg-2 and java-pkg-opt-2: we need phase hooks (and if we get rid of needing phase hooks, we will need 2.1.1 for proper env saving) virtual/portage is old-style virtual, how will that map to other package managers if we specify portage version we need? I guess badly.
(In reply to comment #1) > > virtual/portage is old-style virtual, how will that map to other package > managers if we specify portage version we need? I guess badly. > Yeah that would not work. Also java-config atm needs Portage so you really can't uninstall it either even if the env hooks worked.
virtual/portage is an old style virtual so it does not help us here betelgeuse@pena ~ $ qgrep -H virtual/portage sys-apps/paludis/paludis-0.14.3.ebuild: PROVIDE="virtual/portage" sys-apps/paludis/paludis-0.16.0.ebuild: PROVIDE="virtual/portage" sys-apps/paludis/paludis-0.16.1.ebuild: PROVIDE="virtual/portage" sys-apps/portage/portage-2.0.51.22-r3.ebuild: PROVIDE="virtual/portage" sys-apps/portage/portage-2.1.1-r2.ebuild: PROVIDE="virtual/portage" ATM I can't think of a reason to need that depend in java-vm-2.eclass but it will stay in java-utils-2.eclass for the time being.
Can't the eclass's dependency be changed to || ( >=sys-apps/portage-2.1 sys-apps/pkgcore sys-apps/paludis ) ?
(In reply to comment #4) > Can't the eclass's dependency be changed to > > || ( >=sys-apps/portage-2.1 sys-apps/pkgcore sys-apps/paludis ) > > ? > I for example have paludis installed but don't use it to install anything. I just query stuff with it so you're solution is not enough.
(In reply to comment #5) > (In reply to comment #4) > > Can't the eclass's dependency be changed to > > > > || ( >=sys-apps/portage-2.1 sys-apps/pkgcore sys-apps/paludis ) > > > > ? > > > > I for example have paludis installed but don't use it to install anything. I > just query stuff with it so you're solution is not enough. The only reason this wouldn't work is if you installed paludis, uninstalled portage, then complained that you only wanted paludis for queries and wanted to use portage to install stuff (which would make us wonder why you uninstalled portage to begin with).
(In reply to comment #6) > The only reason this wouldn't work is if you installed paludis, uninstalled > portage, then complained that you only wanted paludis for queries and wanted to > use portage to install stuff (which would make us wonder why you uninstalled > portage to begin with). No, it wouldn't work in this scenario: install portage < 2.1 and paludis/pkgcore try to install anything with java-vm-2 eclass (via portage) I don't think portage would update itself to >2.1 if the || dependency would be already satisfied by paludis/pkgcore
(In reply to comment #7) > (In reply to comment #6) > > The only reason this wouldn't work is if you installed paludis, uninstalled > > portage, then complained that you only wanted paludis for queries and wanted to > > use portage to install stuff (which would make us wonder why you uninstalled > > portage to begin with). > > No, it wouldn't work in this scenario: > install portage < 2.1 and paludis/pkgcore > try to install anything with java-vm-2 eclass (via portage) > I don't think portage would update itself to >2.1 if the || dependency would be > already satisfied by paludis/pkgcore > So then can this be fixed with the following 2 lines? || ( >=sys-apps/portage-2.1 sys-apps/pkgcore sys-apps/paludis ) !<sys-apps/portage-2.1 So the eclass would have a block for old versions of portage and would allow the other managers too.
(In reply to comment #8) > > > > So then can this be fixed with the following 2 lines? > || ( >=sys-apps/portage-2.1 sys-apps/pkgcore sys-apps/paludis ) > !<sys-apps/portage-2.1 > I doubt this would make a good upgrade path from <portage-2.1 to current versions. You really can't uninstall the package manager to get around the block.
any news on this one? portage-2.1.4.5 is the oldest portage in the tree... that should take care of the FIXME in java-pkg.eclass. what about java-utils-2.eclass and java-vm-2.eclass?
(In reply to comment #10) > any news on this one? portage-2.1.4.5 is the oldest portage in the tree... > > that should take care of the FIXME in java-pkg.eclass. > what about java-utils-2.eclass and java-vm-2.eclass? > java-pkg.eclass is deprecated and will be gone soon. The eclasses don't require sys-apps/portage when you have EAPI 2 so the dep will be gone when all ebuilds using the eclasses are EAPI 2.
I dropped the dep in June last year because the eclass now requires EAPI 5+.
