A lot of ebuilds depens on an old portage version that is no more available (the oldest portage in the tree is 2.0.51.22-r3). Here is the list of those ebuilds in the tree. I didn't have a look wether or not the dependency is still needed (I think not in most of case), I tried to apply virtual/portage instead of sys-apps/portage for all except the one that really depends on portage itself (not pkgcore or paludis) If you want I can provided patches for all of those. the list : app-admin/logrotate (all) depend on >=sys-apps/portage-2.0.47-r10 virtual/portage app-admin/syslog-ng-1.6.9 : >=sys-apps/portage-2.0.51 => virtual/portage app-admin/syslog-ng-1.6.11-r1 : >=sys-apps/portage-2.0.51 => virtual/portage app-backup/amanda (all) : >=sys-apps/portage-2.0.51-r3 => virtual/portage app-portage/abeni (all): >=sys-apps/portage-2.0.46-r12 => sys-apps/portage app-portage/esearch (all) : >=sys-apps/portage-2.0.50 => sys-apps/portage app-portage/porthole (all) : >=sys-apps/portage-2.0.51-r3 => sys-apps/portage dev-db/cdb (all) : >=sys-apps/portage-2.0.47-r10 => virtual/portage dev-games/crystalspace (all) : >=sys-apps/portage-2.0.51 => virtual/portage dev-games/crystalspace-cvs : >=sys-apps/portage-2.0.51 => virtual/portage dev-lang/tk (all) : >=sys-apps/portage-2.0.47-r10 => virtual/portage dev-tcltk (all) : >=sys-apps/portage-2.0.47-r10 => virtual/portage dev-util/fenris : >=sys-apps/portage-2.0.47-r10 => virtual/portage media-sound/aumix : >=sys-apps/portage-2.0.51 => virtual/portage media-tv/xmltv : >=sys-apps/portage-2.0.50-r1 => virtual/portage net-dns/dnsmasq : >=sys-apps/portage-2.0.51 => virtual/portage net-fs/am-utils : >=sys-apps/portage-2.0.51 => virtual/portage net-fs/nfs-utils : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/dropbear : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/knock : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/lsh : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/rwho : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/ntp : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/openntpd : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/rinetd : >=sys-apps/portage-2.0.51 => virtual/portage net-misc/rsync : >=sys-apps/portage-2.0.51 => virtual/portage net-nds/portmap : >=sys-apps/portage-2.0.51 => virtual/portage net-nds/ypbind : >=sys-apps/portage-2.0.51 => virtual/portage net-nds/portmap : >=sys-apps/portage-2.0.51 => virtual/portage sys-apps/attr : >=sys-apps/portage-2.0.47-r10 => virtual/portage sys-apps/baselayout : >=sys-apps/portage-2.0.51 => virtual/portage sys-apps/baselayout-vserver : >=sys-apps/portage-2.0.51 => virtual/portage sys-apps/microcode-ctl : >=sys-apps/portage-2.0.51 => virtual/portage sys-apps/shadow : >=sys-apps/portage-2.0.51-r2 => virtual/portage sys-apps/smartmontools : >=sys-apps/portage-2.0.51 => virtual/portage sys-devel/distcc : >=sys-apps/portage-2.0.49-r6 => virtual/portage sys-process/at : >=sys-apps/portage-2.0.51 => virtual/portage sys-process/dcron : >=sys-apps/portage-2.0.51 => virtual/portage sys-process/vixie-cron : >=sys-apps/portage-2.0.47-r10 => virtual/portage x11-base/kdrive : >=sys-apps/portage-2.0.49-r13 => virtual/portage x11-base/x11-drm : >=sys-apps/portage-2.0.49-r13 => virtual/portage x11-misc/denu : >=sys-apps/portage-2.0.50-r10 => virtual/portage Reproducible: Always Expected Results: some cleanup on the ebuild.
Most of those should just have the dependency dropped altogether. Assigning to QA, would be preferable if someone cleaned up the list first before CCing maintainers for ebuilds that still might need to depend on portage for some reason.
I just add the followinf eclasses : mozilla.eclass >=sys-apps/portage-2.0.36 => virtual/portage mozconfig.eclass >=sys-apps/portage-2.0.36 => virtual/portage
sys-apps/smartmontools fixed in CVS by SpanKY. I will start bugging maintainers and hers.
mozilla eclasses fixed
I cleaned this up tonight..still left are: app-emulation/vmware-modules-1.0.0.11 app-emulation/vmware-modules-1.0.0.13 app-emulation/vmware-modules-1.0.0.15-r1 app-portage/emerge-delta-webrsync-3.3 app-portage/emerge-delta-webrsync-3.5.1 app-portage/esearch-0.7.1 app-portage/esearch-0.7.1-r2 app-portage/esearch-0.7.1-r3 app-portage/esearch-0.7.1-r4 app-portage/gentoolkit-0.2.2 app-portage/gentoolkit-dev-0.2.6.2 app-shells/sandboxshell-0.3-r1 dev-games/crystalspace-0.98.4 games-arcade/smclone-0.97 media-sound/aumix-2.8-r4 sys-apps/baselayout-1.11.15-r3 sys-apps/baselayout-1.12.4-r7 sys-apps/baselayout-1.12.5-r2 sys-apps/baselayout-1.12.6 sys-apps/baselayout-1.12.9 sys-apps/baselayout-vserver-1.11.14-r4 sys-apps/microcode-ctl-1.14 sys-apps/microcode-ctl-1.15 x11-base/kdrive-4.3.0-r5 x11-misc/denu-2.3.2 app-portage/eix-0.6.4 app-portage/porthole-0.4.1 app-portage/porthole-0.5.0 net-misc/ntp-4.2.2_p3 net-misc/rsync-2.6.9-r1 Some legitimately depend on portage (porthole for instance).
(In reply to comment #5) > app-emulation/vmware-modules-1.0.0.11 > app-emulation/vmware-modules-1.0.0.13 > app-emulation/vmware-modules-1.0.0.15-r1 vmware-mods.eclass, actually... but I'm not splitting hairs... it's fixed. > dev-games/crystalspace-0.98.4 > games-arcade/smclone-0.97 Fixed.
glibc 2.5-r2 and 2.6 depend on >=sys-apps/portage-2.1.2 mplayer does as well depending on USE flag Instead, it seems the dependency could be changed to "|| ( >=sys-apps/portage-2.1.2 sys-apps/pkgcore sys-apps/paludis )" which appears to be the way this was fixed in python-updater
(In reply to comment #7) > glibc 2.5-r2 and 2.6 depend on >=sys-apps/portage-2.1.2 > > mplayer does as well depending on USE flag > > Instead, it seems the dependency could be changed to "|| ( > >=sys-apps/portage-2.1.2 sys-apps/pkgcore sys-apps/paludis )" which appears to > be the way this was fixed in python-updater > This solution doesn't work. For example, I could have pkgcore installed for some random reason, but use portage to install applications. pkgcore would be installed and satisfy this dependency but I could have <sys-apps/portage-2.1.2 installed.
A solution I came up a while ago was to have a PM hidden USE_EXPAND variable so one could depend on pm_portage? ( >=sys-apps/portage-<version> ). Ciaranm did not like this idea. I also don't know if it would be possible to implement it so that it would be supported by older Portage versions (via bashrc etc).
Portage guys: Any suggestions on how we should handle this?
Has to be handled on a case by case basis. The main question is if it's the ebuild depending on some (E)API thing or the actual package requiring emerge/portageq/the portage API. As for the USE_EXPAND idea, that would only work with some automagic in the package manager, and I generally dislike automagic/special cases.
*** Bug 257674 has been marked as a duplicate of this bug. ***
the tinderbox has a list of all ebuilds depending on portage directly. i'll file individual bugs for each of those (where it makes sense)... the java eclasses (#163504) seem to be responsible for many occurrences.
*** Bug 263694 has been marked as a duplicate of this bug. ***
Revisiting this again... These could be just changed to !<sys-apps/portage-${version.that.fixes.my.bug}, and make everyone happy, right?
if the corresponding portage version no longer is in the tree, then the dep can be removed altogether.
(In reply to comment #15) > Revisiting this again... > > These could be just changed to !<sys-apps/portage-${version.that.fixes.my.bug}, > and make everyone happy, right? > I suggest migrating them all to EAPI 2 (it has a nice effect of forcing a quite recent Portage).
(In reply to comment #17) > (In reply to comment #15) > > Revisiting this again... > > > > These could be just changed to !<sys-apps/portage-${version.that.fixes.my.bug}, > > and make everyone happy, right? > > > > I suggest migrating them all to EAPI 2 (it has a nice effect of forcing a quite > recent Portage). > Yea, I don't really feel comfortable doing that to glibc yet though. I thought we were holding off on system packages atleast.
(In reply to comment #18) > > Yea, I don't really feel comfortable doing that to glibc yet though. I thought > we were holding off on system packages atleast. > As long as it's not directly in the deptree of Portage it should be fine as upgrading Portage works but feel free to check the details with zmedico. It seems python:2.6 is EAPI=2 so having glibc shouldn't hurt any more.
Generally, EAPI 2 is fine for anything, including system packages, as long as there's an upgrade path for the user to get to portage-2.1.6.x. For example, someone can upgrade from portage-2.1.4.x to portage-2.1.6.x, and having python-2.5 be EAPI 2 doesn't hurt them since they've already got an older python (2.4 or 2.5) that portage-2.1.6.x can use to satisfy its python dependency.
