162516 2007-01-17 11:14 0000 [TRACKER] ebuilds with dependencies on sys-apps/portage 2009-07-07 18:54:39 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux NEW http://tinderbox.dev.gentoo.org/misc/rindex/sys-apps/portage Tracker P2 trivial --- 163504 163507 167410 167411 167415 263669 263694 263696 263698 263699 1 baptiste.daroussin@gmail.com qa@gentoo.org antarus@gentoo.org bangert@gentoo.org dirk.heinrichs@online.de fuzzyray@gentoo.org moloh@gentoo.org zmedico@gentoo.org baptiste.daroussin@gmail.com 2007-01-17 11:14:16 0000 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. jakub@gentoo.org 2007-01-17 11:26:12 0000 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. baptiste.daroussin@gmail.com 2007-01-17 13:26:43 0000 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 moloh@gentoo.org 2007-01-23 22:42:59 0000 sys-apps/smartmontools fixed in CVS by SpanKY. I will start bugging maintainers and hers. genstef@gentoo.org 2007-02-27 17:03:18 0000 mozilla eclasses fixed antarus@gentoo.org 2007-03-26 08:20:12 0000 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). wolf31o2@gentoo.org 2007-03-26 14:57:56 0000 (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. cslycord@gmail.com 2007-05-31 23:32:02 0000 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 halcy0n@gentoo.org 2007-12-31 00:56:23 0000 (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. betelgeuse@gentoo.org 2008-01-02 20:07:47 0000 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). halcy0n@gentoo.org 2008-01-15 01:15:50 0000 Portage guys: Any suggestions on how we should handle this? genone@gentoo.org 2008-01-15 14:29:42 0000 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. halcy0n@gentoo.org 2009-02-05 22:50:32 0000 *** Bug 257674 has been marked as a duplicate of this bug. *** bangert@gentoo.org 2009-03-24 21:31:39 0000 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. robbat2@gentoo.org 2009-04-01 07:54:27 0000 *** Bug 263694 has been marked as a duplicate of this bug. *** halcy0n@gentoo.org 2009-05-03 19:00:44 0000 Revisiting this again... These could be just changed to !<sys-apps/portage-${version.that.fixes.my.bug}, and make everyone happy, right? bangert@gentoo.org 2009-05-04 08:11:51 0000 if the corresponding portage version no longer is in the tree, then the dep can be removed altogether. betelgeuse@gentoo.org 2009-05-04 13:23:39 0000 (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). halcy0n@gentoo.org 2009-05-04 15:13:44 0000 (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. betelgeuse@gentoo.org 2009-05-05 00:17:43 0000 (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. zmedico@gentoo.org 2009-05-05 00:57:41 0000 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.