Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.