Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 162516 - [TRACKER] ebuilds with dependencies on sys-apps/portage
Summary: [TRACKER] ebuilds with dependencies on sys-apps/portage
Status: CONFIRMED
Alias: None
Product: Quality Assurance
Classification: Unclassified
Component: Trackers (show other bugs)
Hardware: All Linux
: High trivial
Assignee: Gentoo Quality Assurance Team
URL: http://tinderbox.dev.gentoo.org/misc/...
Whiteboard:
Keywords: Tracker
: 257674 263694 (view as bug list)
Depends on: 163504 163507 167410 167411 167415 263669 263694 263696 263698 263699
Blocks:
  Show dependency tree
 
Reported: 2007-01-17 11:14 UTC by Bapt
Modified: 2021-07-21 00:48 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bapt 2007-01-17 11:14:16 UTC
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.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-01-17 11:26:12 UTC
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.
Comment 2 Bapt 2007-01-17 13:26:43 UTC
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
Comment 3 Michal Kurgan (RETIRED) gentoo-dev 2007-01-23 22:42:59 UTC
sys-apps/smartmontools fixed in CVS by SpanKY.
I will start bugging maintainers and hers.
Comment 4 Stefan Schweizer (RETIRED) gentoo-dev 2007-02-27 17:03:18 UTC
mozilla eclasses fixed
Comment 5 Alec Warner (RETIRED) archtester gentoo-dev Security 2007-03-26 08:20:12 UTC
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).
Comment 6 Chris Gianelloni (RETIRED) gentoo-dev 2007-03-26 14:57:56 UTC
(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.
Comment 7 Chris Slycord 2007-05-31 23:32:02 UTC
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
Comment 8 Mark Loeser (RETIRED) gentoo-dev 2007-12-31 00:56:23 UTC
(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.
Comment 9 Petteri Räty (RETIRED) gentoo-dev 2008-01-02 20:07:47 UTC
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).
Comment 10 Mark Loeser (RETIRED) gentoo-dev 2008-01-15 01:15:50 UTC
Portage guys:

Any suggestions on how we should handle this?
Comment 11 Marius Mauch (RETIRED) gentoo-dev 2008-01-15 14:29:42 UTC
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.
Comment 12 Mark Loeser (RETIRED) gentoo-dev 2009-02-05 22:50:32 UTC
*** Bug 257674 has been marked as a duplicate of this bug. ***
Comment 13 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2009-03-24 21:31:39 UTC
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.
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-04-01 07:54:27 UTC
*** Bug 263694 has been marked as a duplicate of this bug. ***
Comment 15 Mark Loeser (RETIRED) gentoo-dev 2009-05-03 19:00:44 UTC
Revisiting this again...

These could be just changed to !<sys-apps/portage-${version.that.fixes.my.bug}, and make everyone happy, right?
Comment 16 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2009-05-04 08:11:51 UTC
if the corresponding portage version no longer is in the tree, then the dep can be removed altogether.
Comment 17 Petteri Räty (RETIRED) gentoo-dev 2009-05-04 13:23:39 UTC
(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).
Comment 18 Mark Loeser (RETIRED) gentoo-dev 2009-05-04 15:13:44 UTC
(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.
Comment 19 Petteri Räty (RETIRED) gentoo-dev 2009-05-05 00:17:43 UTC
(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.
Comment 20 Zac Medico gentoo-dev 2009-05-05 00:57:41 UTC
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.