Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
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.
