[gentoo-dev] Portage: missing pieces

[gentoo-dev] Portage: missing pieces

[Molle Bestefich]

I think a piece might be missing from Portage.

I'll depict my workflow as an example.

I'm preparing to upgrade:
# emerge --sync
# emerge -Dp world
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXinerama-1.0.1)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXi-1.0.1)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXrandr-1.1.1)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/randrproto-1.1.2)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking x11-misc/makedepend-1.0.0)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking media-libs/mesa-6.5-r3)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libdrm-2.0.1)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking
x11-proto/xf86vidmodeproto-2.2.2)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/glproto-1.4.7)
[blocks B     ] <=x11-base/xorg-x11-6.9 (is blocking
x11-proto/xf86driproto-2.0.3)
... etc, lots of blockers ...

Ok, let's try and find why it wants to downgrade to xorg-x11-6.9:
# equery d xorg-x11-6.9
[ Searching for packages depending on xorg-x11-6.9... ]

<none found>
#

Ok, no reason, apparently.  Maybe it's already merged then?
# emerge -C xorg-x11-6.9
--- Couldn't find 'xorg-x11-6.9' to unmerge.

Nope.  Now I'm getting uncertain.  Don't I have xorg-x11 at all?
# emerge -C xorg-x11

 x11-base/xorg-x11
    selected: 7.0-r1
   protected: none
     omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3

<CTRL-C>
Exiting on signal 2

Whoops.  Yep, it's there.

Ok, so status is that I have xorg-x11-7.0, I don't have 6.9,
no packages actually wants xorg-x11-6.9, but whenever I use
"emerge -D world", Portage sees it as a blocker anyway.

Is there a piece missing in this puzzle, in particular the one that
will tell me why on earth Portage thinks version 6.9 is a blocker?

Or is the piece in place but I'm not looking hard enough?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage: missing pieces

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Molle Bestefich wrote:
> Ok, so status is that I have xorg-x11-7.0, I don't have 6.9,
> no packages actually wants xorg-x11-6.9, but whenever I use
> "emerge -D world", Portage sees it as a blocker anyway.
> 
> Is there a piece missing in this puzzle, in particular the one that
> will tell me why on earth Portage thinks version 6.9 is a blocker?
> 
> Or is the piece in place but I'm not looking hard enough?

I already replied to your post on -user. In the future, please don't
post the same thing to multiple lists.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Molle Bestefich wrote:
> I think a piece might be missing from Portage.
>
> I'll depict my workflow as an example.

Same thing with a package called 'seamonkey':

# emerge -Dpt world
These are the packages that would be merged, in reverse order:
Calculating world dependencies... done!
[blocks B     ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
[blocks B     ] >=sys-apps/shadow-4.0.14-r2 (is blocking
sys-apps/pam-login-4.0.14)
[blocks B     ] sys-apps/pam-login (is blocking sys-apps/shadow-4.0.15-r2)
... etc ...

# emerge --unmerge seamonkey
--- Couldn't find 'seamonkey' to unmerge.
>>> No packages selected for removal by unmerge.

# equery d seamonkey
[ Searching for packages depending on seamonkey... ]

#

Nobody wants a seamonkey, and I haven't got one already, but Portage
wants to smuggle one in anyway if I tell it to upgrade world.

Where's the piece that can tell me why Portage wants to do so?

(Alternatively, what's the manual process to find out?)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Daniel Drake]

Molle Bestefich wrote:
> Same thing with a package called 'seamonkey':

Same answer as you got on the -user list: use --tree
But don't only look at the top section of the output.

Daniel

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

> Dont "snip".  The relevant part comes *after* the "blocks" lines.

Aah.  I get it.  Thanks.
Sorry for the noise.

> > www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
>
> Also, you are mis-interpreting the "blocks" lines.  The correct
> reading of "X (is blocking Y)" is that you have (or should have)
> X installed, and now portage wants to install Y instead.
> Usually this is because Y supercedes the functionality that used
> to be provided by X, and  in almost all cases, the right thing
> to do is to unmerge X and merge Y.

Evolution depends on Mozilla and Mono depends on SeaMonkey.  Mono is
the "newer" (actively developed... sort of) component, also, from what
I've heard, SeaMonkey is based on a vastly newer version of Gecko.  So
I'm not sure how that fits with the above.

Anyway, I tried unmerging SeaMonkey and merging Mozilla, which went fine.
Doesn't help any with the blocker status, though.

So I'm stuck here.
Is it impossible to have Mono and Evolution installed at the same time?

(Same story with OpenSSH and pam-login.  OpenSSH wants shadow, and
pam-login refuses to merge alongside shadow.  I want both pam-login
and OpenSSH, but seems like I'll have to choose, right?)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Pierre Guinoiseau]

> (Same story with OpenSSH and pam-login.  OpenSSH wants shadow, and
> pam-login refuses to merge alongside shadow.  I want both pam-login
> and OpenSSH, but seems like I'll have to choose, right?)

pam-login is now included in shadow, you no longer need to emerge it.

-- 

 Pierre Guinoiseau
 Email: songoku38@gmail.com
 M$N: songoku38@gmail.com
 Jabber: lnx@jabber.fr


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Richard Fish]

On 7/6/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
> Evolution depends on Mozilla and Mono depends on SeaMonkey.

I don't think this is right, at least not for what is currently in
portage.  When I do a

USE="mono" emerge -Devp evolution

No mozilla comes in.  So evolution does not depend on mozilla, at
least not directly.

In fact, in the current portage tree, mozilla is going away, and being
replaced by seamonkey.  Very few (and hard masked) packages like
gecko-sdk still depend on mozilla.  So what you should eventually end
up with is no mozilla but seamonkey.

> So I'm stuck here.
> Is it impossible to have Mono and Evolution installed at the same time?

No, it is certainly possible, as I have both on my system.

Are you using an portage overlay?  If so, what is in it?

When was the last time you did an emerge --sync?

Also, the full output of "emerge -Duvpt world" would still be useful
for us to see.

-Richard
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Pierre Guinoiseau writes:
> pam-login is now included in shadow, you no longer need to emerge it.

Thanks, that's what I needed to know.
I had done an emerge -D world, and suddenly I couldn't "turn on the
PC".  I later found out that /sbin/login had been removed.

Richard Fish writes:
> USE="mono" emerge -Devp evolution
>
> No mozilla comes in.
> So evolution does not depend on mozilla, at least not directly.

Ok.  Same picture here.  (Above command pulls in 402 other packages
though... caramba)

> In fact, in the current portage tree, mozilla is going away, and
> being replaced by seamonkey.  Very few (and hard masked) packages
> like gecko-sdk still depend on mozilla.  So what you should
> eventually end up with is no mozilla but seamonkey.

Thanks for the info!

> Are you using an portage overlay?  If so, what is in it?

No.  No idea what that is.  Sounds interesting, though.

> When was the last time you did an emerge --sync?

Yesterday.  It changed things a bit since last time (month ago?), but
it still wants to merge mozilla.  Only now it's mono-tools (or rather
gecko-sharp) that wants it, Evolution is out of the picture:

[nomerge      ] dev-util/mono-tools-1.1.11
[ebuild  N    ]  dev-dotnet/gecko-sharp-0.6
[nomerge      ]   www-client/mozilla-1.7.13

> Also, the full output of "emerge -Duvpt world"

Attached.

Note that I got rid of the Xorg-6.9 blockers by merging virtual/xft-7.0.
Doesn't make any sense to me at all, explanations sought for :-).

[-- Attachment #2: Duvpt.txt --]
[-- Type: text/plain, Size: 27022 bytes --]


These are the packages that would be merged, in reverse order:

Calculating world dependencies  ..... ..... 
!!! Packages for the following atoms are either all
!!! masked or don't exist:
media-tv/atitvout

\b\b... done!
[blocks B     ] www-client/seamonkey (is blocking www-client/mozilla-1.7.13)
[blocks B     ] www-client/mozilla (is blocking www-client/seamonkey-1.0.2)
[ebuild     U ] kde-base/kwalletmanager-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 2,910 kB 
[ebuild     U ] sys-fs/device-mapper-1.02.07 [1.02.02] 902 kB 
[ebuild     U ] kde-base/kdebase-meta-3.5.3 [3.5.2] 0 kB 
[ebuild     U ]  kde-base/konsole-3.5.3-r1 [3.5.2-r1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 6 kB 
[ebuild     U ]  kde-base/ksysguard-3.5.3-r1 [3.5.2-r2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% -lm_sensors -zeroconf" 0 kB 
[ebuild     U ]  kde-base/knetattach-3.5.3 [3.5.1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kdeprint-3.5.3 [3.5.2] USE="cups kde xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/kghostview-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 7,129 kB 
[ebuild     U ]  kde-base/ktip-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kate-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kscreensaver-3.5.3 [3.5.1] USE="opengl xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kmenuedit-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kpager-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/drkonqi-3.5.3-r1 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kappfinder-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kxkb-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 5 kB 
[ebuild     U ]  kde-base/klipper-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[nomerge      ] app-cdr/k3b-0.12.14  USE="alsa encode ffmpeg flac kde mp3 sndfile* vorbis xinerama -arts* -css -debug -dvdr -hal -musepack -musicbrainz -vcd" 
[ebuild     U ]  app-cdr/cdrdao-1.2.1-r1 [1.2.1] USE="encode gnome -debug -pccts" 0 kB 
[nomerge      ]   dev-cpp/gtkmm-2.8.1  USE="-debug" 
[ebuild     U ]    dev-cpp/glibmm-2.8.4 [2.8.1] USE="doc* -debug" 1,977 kB 
[ebuild     U ] kde-base/konq-plugins-3.5.3 [3.5.2-r1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 1,607 kB 
[ebuild     U ]  kde-base/konqueror-3.5.3 [3.5.2] USE="java xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/kfind-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ] dev-libs/openobex-1.2-r1 [1.0.1] USE="bluetooth% -debug% -irda% -syslog% -usb%" 333 kB 
[nomerge      ] media-video/konverter-0.92_beta1  USE="xinerama -arts* -debug" 
[ebuild     U ]  media-libs/xine-lib-1.1.2_pre20060328-r9 [1.1.2_pre20060328-r1] USE="X aac alsa asf directfb esd* fbcon ffmpeg flac gnome ipv6 mad opengl oss sdl theora vorbis win32codecs xinerama xv -a52 -aalib -arts* -debug -dts -dvd -dxr3 -imagemagick -libcaca -mng -modplug -samba -speex -v4l -vcd -vidix -xvmc" VIDEO_CARDS="-i810 -nvidia -via" 36 kB 
[ebuild     U ] sys-apps/coldplug-20040920-r1 [20040920] 0 kB 
[ebuild     U ] sys-process/psmisc-22.2 [22.1] USE="X ipv6 nls" 238 kB 
[ebuild     U ] sys-process/lsof-4.76 [4.75] USE="-static" 971 kB 
[ebuild  N    ] x11-themes/mythtv-themes-0.19  9,261 kB 
[ebuild     U ] media-tv/mythtv-0.19_p9163-r1 [0.18.1-r1] USE="alsa jack* opengl vorbis -backendonly% -dbox2% -debug -dvb -dvd% -frontendonly -ieee1394% -joystick -lcd -lirc -mmx -xvmc%" VIDEO_CARDS="-i810% -nvidia% -via%" 9,940 kB 
[nomerge      ] app-emulation/wine-0.9.8-r1  USE="X alsa cups esd gif jack* jpeg ncurses opengl oss truetype xml% -arts* -debug -glut* -lcms* -ldap -nas -scanner" 
[ebuild     U ]  media-gfx/fontforge-20060703 [20060408] USE="X gif jpeg png svg truetype unicode -tiff" 3,282 kB 
[ebuild     U ] net-wireless/bluez-utils-2.25-r1 [2.24] USE="alsa cups gtk udev -dbus -pcmcia" 578 kB 
[ebuild     U ]  net-wireless/bluez-libs-2.25 [2.24] 284 kB 
[ebuild     U ] media-sound/mpg123-0.59s-r11 [0.59s-r9] USE="esd oss -3dnow -mmx -nas" 7 kB 
[ebuild     U ] kde-base/kopete-3.5.3-r1 [3.5.2] USE="ssl xinerama xmms -arts -debug -kdeenablefinal -kdehiddenvisibility% -sametime" 7,351 kB 
[nomerge      ] dev-util/mono-tools-1.1.11  
[ebuild  N    ]  dev-dotnet/gecko-sharp-0.6  0 kB 
[nomerge      ]   www-client/mozilla-1.7.13  USE="crypt gnome ipv6 java ssl truetype xinerama -debug -ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznoxft -mozsvg -postgres -xprint" 
[nomerge      ] dev-util/cogito-0.16.4  USE="doc" 
[ebuild     U ]  net-misc/rsync-2.6.8-r2 [2.6.0-r6] USE="ipv6% -acl* -build -static -xinetd" 754 kB 
[ebuild     U ]  app-text/asciidoc-7.0.4 [7.0.1] 728 kB 
[ebuild     U ] sys-apps/less-394 [385_p4-r2] USE="unicode*" 285 kB 
[nomerge      ] net-im/gaim-1.5.0  USE="eds nls perl spell -cjk -debug -gnutls -minimal% -nas -silc -tcltk" 
[nomerge      ]  app-text/gtkspell-2.0.11-r1  USE="doc" 
[ebuild     U ]   app-text/enchant-1.2.5 [1.1.6] 519 kB 
[nomerge      ]  gnome-extra/evolution-data-server-1.4.2.1  USE="doc* ipv6 ssl -debug -kerberos -krb4 -ldap -nntp" 
[ebuild     U ]   net-libs/libsoup-2.2.94 [2.2.7] USE="doc* ssl -debug -static" 471 kB 
[ebuild     U ] net-print/hplip-1.6.6-r1 [1.6.6] USE="X foomaticdb ppds qt3% scanner -snmp" 10,202 kB 
[nomerge      ]  net-print/foomatic-db-engine-3.0.2  USE="-minimal%" 
[ebuild     U ]   net-print/foomatic-filters-3.0.2-r1 [3.0.2] USE="cups -samba*" 0 kB 
[nomerge      ]  dev-python/PyQt-3.14.1-r1  USE="doc* -debug -examples" 
[nomerge      ]   dev-python/sip-4.2.1  USE="doc* -debug" 
[ebuild  NS   ]    x11-libs/qt-4.1.2  USE="cups doc gif jpeg mysql opengl png xinerama zlib -accessibility -debug -examples -firebird -mng -nas -nis -odbc -postgres -sqlite" 27,269 kB 
[ebuild     U ] kde-base/kdebase-startkde-3.5.3-r1 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kpersonalizer-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/ksplashml-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kdesktop-3.5.3-r1 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% -xscreensaver" 0 kB 
[ebuild     U ]   kde-base/kdm-3.5.3-r2 [3.5.2] USE="pam xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]    kde-base/kdepasswd-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/ksmserver-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ] app-portage/kuroo-0.80.2 [0.80.1] USE="xinerama -arts* -debug" 753 kB 
[ebuild     U ]  app-portage/gentoolkit-0.2.2 [0.2.1] 84 kB 
[ebuild     U ] net-misc/telnet-bsd-1.2-r1 [1.2] USE="nls" 0 kB 
[nomerge      ] media-video/mplayer-1.0_pre8  USE="X aac aalib alsa cdparanoia cpudetection dga directfb doc dts dvd dvdread encode esd fbcon gif gtk i8x0 ipv6 jack jpeg live lzo mad mmx opengl oss png real sdl sse sse2 theora truetype unicode vorbis win32codecs x264 xinerama xmms xv xvid -3dfx -3dnow -3dnowext -arts -bidi -bindist -bl -custom-cflags -debug -dv -dvb -ggi -joystick -libcaca -lirc -livecd -matrox -mmxext -musepack -nas -nvidia -openal -rtc -samba -speex -svga -tga -v4l -v4l2 -xanim -xvmc" 
[ebuild     U ]  media-sound/cdparanoia-3.9.8-r3 [3.9.8-r2] 17 kB 
[ebuild     U ] app-office/koffice-meta-1.5.1 [1.5.0] 0 kB 
[ebuild     U ]  app-office/kugar-1.5.1 [1.5.0] USE="xinerama -arts -debug" 35,166 kB 
[ebuild     U ]  app-office/kexi-1.5.1 [1.5.0] USE="xinerama -arts -debug -mysql -postgres" 0 kB 
[ebuild     U ]  app-office/koshell-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]  app-office/krita-1.5.1 [1.5.0] USE="opengl xinerama -arts -debug" 0 kB 
[ebuild  N    ]   media-libs/openexr-1.2.2  USE="doc" 9,105 kB 
[ebuild  N    ]    x11-libs/fltk-1.1.7  USE="opengl -debug -noxft" 2,012 kB 
[ebuild     U ]  app-office/karbon-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]  app-office/kplato-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]  app-office/kivio-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]  app-office/kformula-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]  app-office/kword-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]   app-text/wv2-0.2.3 [0.2.2] 887 kB 
[ebuild     U ]  app-office/kspread-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]   app-office/kchart-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]  app-office/kpresenter-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ]   app-office/koffice-libs-1.5.1 [1.5.0] USE="doc xinerama -arts -debug" 0 kB 
[ebuild     U ]    app-office/koffice-data-1.5.1 [1.5.0] USE="xinerama -arts -debug" 0 kB 
[ebuild     U ] media-video/vlc-0.8.4a-r1 [0.8.2-r2] USE="X aac alsa cdda esd* fbcon ffmpeg flac matroska mp3 mpeg ncurses nls ogg opengl oss png sdl stream svg theora truetype vorbis win32codecs% xinerama% xml xv -3dfx -a52 -aalib -arts* -avahi% -bidi -cddb% -corba -daap -debug -dts -dvb -dvd -ggi -gnutls -hal% -httpd -joystick -libcaca -lirc -live -mod -rtsp% -samba -screen -shout% -skins% -speex -svga -v4l -vcd -vlm -wxwindows -xosd" 7,032 kB 
[ebuild     U ]  dev-libs/libcdio-0.77 [0.73] USE="nls% -cddb -minimal -nocxx%" 1,909 kB 
[ebuild     U ]  dev-libs/libebml-0.7.6 [0.7.3] 54 kB 
[ebuild     U ] kde-base/kmail-3.5.3 [3.5.2-r1] USE="crypt% xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 12,609 kB 
[ebuild     U ]  kde-base/kdepim-kioslaves-3.5.3 [3.5.2-r1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% -sasl" 0 kB 
[ebuild     U ]   kde-base/libkmime-3.5.3 [3.5.0-r1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/mimelib-3.5.3 [3.5.1-r1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kdebase-kioslaves-3.5.3 [3.5.2] USE="xinerama -arts -debug -hal -kdeenablefinal -kdehiddenvisibility% -ldap -openexr -samba" 0 kB 
[ebuild     U ]   kde-base/kdialog-3.5.3 [3.5.0] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ] media-sound/alsaplayer-0.99.76-r3 [0.99.76] USE="alsa audiofile% doc* esd flac jack* mikmod nls ogg% opengl oss vorbis -nas -xosd%" 0 kB 
[ebuild     U ] kde-base/ksnapshot-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ] media-video/totem-1.2.1-r1 [1.2.1] USE="flac gnome mad mpeg nsplugin ogg theora* vorbis win32codecs* xv -a52 -debug -dvd -firefox% -lirc -xine" 0 kB 
[ebuild     U ]  sys-apps/dbus-0.61-r1 [0.60-r4] USE="X doc* gtk python qt3% -debug -mono" 1,695 kB 
[nomerge      ]  media-plugins/gst-plugins-pitfdll-0.8.1-r1  
[ebuild     U ]   media-libs/win32codecs-20060611 [20050412] USE="quicktime real" 13,483 kB 
[ebuild  N    ]  www-client/seamonkey-1.0.2  USE="crypt gnome ipv6 java xinerama -debug -ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznoroaming -postgres -xprint" 35,162 kB 
[ebuild  N    ]   dev-libs/nss-3.11-r1  4,885 kB 
[ebuild     U ] kde-base/nsplugins-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ] app-cdr/dvd+rw-tools-6.1-r1 [5.21.4.10.8] 118 kB 
[ebuild     U ] net-misc/dhcpcd-2.0.5 [2.0.3] USE="-build -debug -static" 121 kB 
[nomerge      ] media-plugins/xmms-wma-1.0.5  
[nomerge      ]  media-video/ffmpeg-0.4.9_p20051216  USE="aac doc encode imlib ogg oss sdl theora truetype vorbis zlib -a52 -debug -dts -ieee1394 -mmx -network -test -threads -v4l -xvid" 
[ebuild  N    ]   media-libs/faad2-2.0-r11  USE="xmms" 8 kB 
[ebuild  N    ]    media-libs/libmp4v2-1.4.1  4,678 kB 
[ebuild     U ] net-analyzer/ethereal-0.99.0 [0.10.14] USE="gtk ipv6 ssl -adns -kerberos -snmp -threads%" 8,676 kB 
[ebuild     U ] kde-base/kuickshow-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ] sys-process/vixie-cron-4.1-r9 [4.1-r8] USE="pam -debug" 0 kB 
[ebuild     U ] kde-base/kmines-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 10,476 kB 
[ebuild     U ]  kde-base/libkdegames-3.5.3 [3.5.1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ] games-engines/scummvm-0.9.0 [0.8.2] USE="alsa flac* mp3 ogg sdl vorbis zlib -debug -fluidsynth%" 4,205 kB 
[nomerge      ] media-gfx/gimp-2.2.8-r1  USE="doc* jpeg png python svg* -aalib* -debug -gimpprint -gtkhtml* -hardened -lcms* -mmx -mng* -smp -sse -tiff* -wmf" 
[ebuild     U ]  gnome-base/librsvg-2.12.7-r1 [2.12.7] USE="doc* gnome zlib -debug" 0 kB 
[ebuild     U ] kde-base/kontact-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/libkpimidentities-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/libkdepim-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]    kde-base/libkcal-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]     kde-base/ktnef-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/certmanager-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]    kde-base/libkpgp-3.5.3 [3.5.0-r1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]    kde-base/libkdenetwork-3.5.3 [3.5.0] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]    app-crypt/gpgme-1.1.2-r1 [1.0.2] 860 kB 
[ebuild     U ] sys-apps/busybox-1.1.3 [1.1.0] USE="-debug -floppyboot -make-symlinks -netboot -savedconfig -static" 1,402 kB 
[ebuild     U ] sys-fs/mdadm-2.5-r1 [1.12.0] USE="ssl% -static" 129 kB 
[ebuild     U ] sys-fs/xfsprogs-2.7.11 [2.7.3] USE="nls" 857 kB 
[nomerge      ] net-p2p/kmldonkey-0.10.1  USE="xinerama -arts -debug" 
[ebuild     U ]  kde-base/kcontrol-3.5.3-r1 [3.5.2] USE="opengl ssl xinerama -arts -debug -ieee1394 -kdeenablefinal -kdehiddenvisibility% -logitech-mouse" 0 kB 
[ebuild     U ]   kde-base/kcminit-3.5.3 [3.5.0] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/khelpcenter-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/khotkeys-3.5.3 [3.5.1] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/kdesu-3.5.3 [3.5.0] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]   kde-base/kicker-3.5.3-r1 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility% -xcomposite" 0 kB 
[ebuild     U ]    kde-base/kdebase-data-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]    kde-base/libkonq-3.5.3 [3.5.2] USE="xinerama -arts -debug -kdeenablefinal -kdehiddenvisibility%" 0 kB 
[ebuild     U ]  kde-base/kdelibs-3.5.3-r3 [3.5.3-r2] USE="alsa cups doc jpeg2k spell ssl xinerama -acl -arts -debug -fam -kdeenablefinal -kdehiddenvisibility -kerberos -legacyssl -openexr -tiff -zeroconf" 15 kB 
[nomerge      ] dev-util/ddd-3.3.10  
[ebuild     U ]  virtual/x11-7.0-r2 [7.0-r1] USE="dri%" 0 kB 
[ebuild     U ]   x11-misc/gccmakedep-1.0.2 [1.0.1-r1] USE="-debug" 68 kB 
[ebuild     U ] x11-drivers/xf86-video-ati-6.6.1 [6.5.7.3] USE="dri -debug" 660 kB 
[ebuild     U ] x11-drivers/xf86-video-imstt-1.1.0 [1.0.0.5] USE="-debug" 228 kB 
[ebuild     U ] x11-drivers/xf86-video-fbdev-0.3.0 [0.1.0.5] USE="-debug" 226 kB 
[ebuild     U ] x11-drivers/xf86-video-sis-0.9.1-r1 [0.8.1.3] USE="dri -debug" 601 kB 
[ebuild     U ] x11-drivers/xf86-video-vesa-1.2.1 [1.0.1.3] USE="-debug" 210 kB 
[ebuild     U ] x11-drivers/xf86-video-tdfx-1.2.1-r1 [1.1.1.3] USE="dri -debug" 263 kB 
[ebuild     U ] x11-drivers/xf86-video-cyrix-1.1.0 [1.0.0.5] USE="-debug" 243 kB 
[ebuild     U ] x11-drivers/xf86-video-s3-0.4.1 [0.3.5.5] USE="-debug" 247 kB 
[ebuild     U ] x11-drivers/xf86-video-tga-1.1.0 [1.0.0.5] USE="-debug" 254 kB 
[ebuild     U ] x11-drivers/xf86-video-glint-1.1.1 [1.0.1.3] USE="dri -debug" 339 kB 
[ebuild     U ] x11-drivers/xf86-video-rendition-4.1.0 [4.0.1.3] USE="-debug" 281 kB 
[ebuild     U ] x11-drivers/xf86-video-nsc-2.8.1 [2.7.6.5] USE="-debug" 481 kB 
[ebuild     U ] x11-drivers/xf86-video-via-0.2.1-r1 [0.1.33.2] USE="dri -debug" 377 kB 
[ebuild     U ] x11-drivers/xf86-video-chips-1.1.1 [1.0.1.3] USE="-debug" 316 kB 
[ebuild     U ] x11-drivers/xf86-video-savage-2.1.1 [2.0.2.3] USE="dri -debug" 281 kB 
[ebuild     U ] x11-drivers/xf86-video-sisusb-0.8.1 [0.7.1.3] USE="-debug" 282 kB 
[ebuild     U ] x11-drivers/xf86-video-mga-1.4.1 [1.2.1.3] USE="dri -debug" 359 kB 
[ebuild     U ] x11-drivers/xf86-video-cirrus-1.1.0 [1.0.0.5] USE="-debug" 257 kB 
[ebuild     U ] x11-drivers/xf86-input-keyboard-1.1.0 [1.0.1.3] USE="-debug" 226 kB 
[ebuild     U ] x11-drivers/xf86-video-trident-1.2.1 [1.0.1.3] USE="-debug" 259 kB 
[ebuild     U ] x11-drivers/xf86-video-i810-1.6.0 [1.4.1.3] USE="dri -debug" 399 kB 
[ebuild     U ] x11-drivers/xf86-video-apm-1.1.1 [1.0.1.5] USE="-debug" 261 kB 
[ebuild     U ] x11-drivers/xf86-input-mouse-1.1.1 [1.0.4] USE="-debug" 261 kB 
[ebuild     U ] x11-drivers/xf86-input-evdev-1.1.2-r1 [1.0.0.5] USE="-debug" 220 kB 
[ebuild     U ] x11-drivers/xf86-video-voodoo-1.1.0 [1.0.0.5] USE="-debug" 238 kB 
[ebuild     U ] x11-drivers/xf86-video-dummy-0.2.0 [0.1.0.5] USE="-debug" 223 kB 
[ebuild     U ] x11-drivers/xf86-video-siliconmotion-1.4.1 [1.3.1.5] USE="-debug" 264 kB 
[ebuild     U ] x11-drivers/xf86-video-i128-1.2.0 [1.1.0.5] USE="-debug" 257 kB 
[ebuild     U ] x11-drivers/xf86-video-i740-1.1.0 [1.0.0.5] USE="-debug" 252 kB 
[ebuild     U ] x11-drivers/xf86-video-neomagic-1.1.1 [1.0.0.5] USE="-debug" 257 kB 
[ebuild     U ] x11-drivers/xf86-video-nv-1.1.2 [1.0.2.0] USE="-debug" 270 kB 
[ebuild     U ] x11-drivers/xf86-video-vmware-10.13.0 [10.12.0.0] USE="-debug" 253 kB 
[ebuild     U ] x11-drivers/xf86-video-s3virge-1.9.1 [1.8.6.5] USE="-debug" 273 kB 
[ebuild     U ] x11-drivers/xf86-video-v4l-0.1.1 [0.0.1.5] USE="-debug" 229 kB 
[ebuild     U ] x11-drivers/xf86-video-vga-4.1.0 [4.0.0.5] USE="-debug" 228 kB 
[ebuild     U ] x11-drivers/xf86-video-tseng-1.1.0 [1.0.0.5] USE="-debug" 261 kB 
[ebuild     U ] x11-drivers/xf86-video-ark-0.6.0 [0.5.0.5] USE="-debug" 225 kB 
[ebuild     U ]   x11-base/xorg-x11-7.1 [7.0-r1] 0 kB 
[ebuild     U ]    x11-base/xorg-server-1.1.0-r1 [1.0.2-r3] USE="dri ipv6 nptl% sdl% xorg% -3dfx% -debug -dmx% -kdrive% -minimal -xprint" INPUT_DEVICES="evdev% keyboard% mouse% -acecad% -aiptek% -calcomp% -citron% -digitaledge% -dmc% -dynapro% -elo2300% -elographics% -fpit% -hyperpen% -jamstudio% -joystick% -magellan% -microtouch% -mutouch% -palmax% -penmount% -spaceorb% -summa% -synaptics% -tek4957% -ur98% -vmmouse% -void% -wacom%" VIDEO_CARDS="-apm% -ark% -chips% -cirrus% -cyrix% -dummy% -epson% -fbdev% -glint% -i128% -i740% -i810% -imstt% -mach64% -mga% -neomagic% -nsc% -nv% -r128% -radeon% -rendition% -s3% -s3virge% -savage% -siliconmotion% -sis% -sisusb% -tdfx% -tga% -trident% -tseng% -v4l% -vesa% -vga% -via% -vmware% -voodoo%" 0 kB 
[ebuild     U ]    x11-apps/mesa-progs-6.5 [6.4.2] 803 kB 
[ebuild     U ]    x11-apps/xrandr-1.0.2 [1.0.1] USE="-debug" 78 kB 
[ebuild     U ]    app-doc/xorg-docs-1.2 [1.1] USE="doc -debug" 8,132 kB 
[nomerge      ] media-fonts/font-alias-1.0.1  USE="-debug" 
[ebuild     U ]   x11-apps/xdm-1.0.5 [1.0.4] USE="ipv6 pam -debug -xprint" 355 kB 
[ebuild  N    ]    x11-apps/sessreg-1.0.0  USE="-debug" 80 kB 
[ebuild     U ] x11-terms/xterm-215 [212-r3] USE="truetype unicode -Xaw3d -toolbar" 765 kB 
[nomerge      ]  sys-libs/libutempter-1.1.2.1  
[nomerge      ]   app-arch/rpm2targz-9.0-r3  
[ebuild     U ]    x11-apps/xinit-1.0.2-r6 [1.0.2-r5] USE="-debug -minimal%" 0 kB 
[ebuild  N    ]   x11-apps/xdriinfo-1.0.1  USE="-debug" 79 kB 
[ebuild     U ]   app-text/rman-3.2 [3.1] 77 kB 
[ebuild     U ] app-editors/nano-1.3.11-r2 [1.3.10-r1] USE="ncurses nls spell unicode -build -debug -justify -minimal -slang" 1,145 kB 
[ebuild  NS   ] media-plugins/gst-plugins-esd-0.10.2  940 kB 
[ebuild  NS   ] media-plugins/gst-plugins-xvideo-0.10.4-r1  1,072 kB 
[ebuild  NS   ] media-plugins/gst-plugins-oss-0.10.2  0 kB 
[ebuild  N    ] media-plugins/gst-plugins-x-0.10.4  0 kB 
[ebuild  NS   ] media-plugins/gst-plugins-alsa-0.10.4  0 kB 
[ebuild  N    ]  media-libs/gst-plugins-base-0.10.4-r1  USE="X alsa esd oss xv -debug" 0 kB 
[nomerge      ] app-cdr/xcdroast-0.98_alpha15-r3  USE="nls -dvdr" 
[ebuild     U ]  app-cdr/cdrtools-2.01.01_alpha10 [2.01.01_alpha07] USE="unicode" 1,464 kB 
[ebuild     U ] dev-util/strace-4.5.14 [4.5.12] USE="-aio -static" 434 kB 
[nomerge      ] media-libs/flac-1.1.2-r3  USE="doc* ogg xmms -3dnow -debug -sse" 
[ebuild     U ]  sys-apps/gawk-3.1.5-r1 [3.1.5] USE="nls -build" 0 kB 
[nomerge      ] app-arch/rpm-4.2  USE="doc* nls python" 
[nomerge      ]  app-crypt/gnupg-1.9.20-r3  USE="X nls -caps -gpg2-experimental -ldap -smartcard" 
[ebuild     U ]   app-crypt/gnupg-1.4.4 [1.4.2.2] USE="X curl* nls readline zlib -bzip2 -ecc -idea -ldap -smartcard -static -usb" 2,975 kB 
[ebuild     U ] sys-apps/man-pages-2.33 [2.32] USE="nls" 1,749 kB 
[nomerge      ] sys-apps/portage-2.1.1_pre2-r4  USE="doc -build" LINGUAS="-pl" 
[ebuild     U ]  sys-apps/debianutils-2.15-r1 [2.15] USE="-build -static" 0 kB 
[nomerge      ]  dev-python/python-fchksum-1.7.1  
[ebuild     U ]   dev-lang/python-2.4.3-r1 [2.4.2] USE="X berkdb doc* gdbm ipv6 ncurses readline ssl -bootstrap -build -nocxx -tcltk -ucs2" 7,827 kB 
[ebuild     U ]    dev-python/python-docs-2.4.3 [2.4.2] 2,296 kB 
[nomerge      ] perl-core/Test-Harness-2.56  USE="-minimal" 
[ebuild     U ]    dev-libs/openssl-0.9.7j [0.9.7i] USE="zlib -bindist -emacs -test" 3,213 kB 
[nomerge      ] dev-perl/DBD-mysql-2.9007  USE="-minimal%" 
[nomerge      ]  dev-perl/DBI-1.50  USE="-minimal" 
[nomerge      ]   dev-perl/PlRPC-0.2018  USE="-minimal%" 
[nomerge      ]    dev-perl/Net-Daemon-0.38  USE="-minimal%" 
[nomerge      ]         media-libs/alsa-lib-1.0.11  USE="doc" 
[ebuild  NS   ]          sys-kernel/gentoo-sources-2.6.16-r11  USE="doc -build -symlink" 230 kB 
[nomerge      ]           app-text/docbook-sgml-utils-0.6.14  USE="-tetex" 
[nomerge      ]            www-client/links-2.1_pre20  USE="X directfb* fbcon* gpm jpeg png sdl ssl unicode* -javascript -livecd -svga -tiff*" 
[nomerge      ]             media-libs/libsdl-1.2.8-r1  USE="X alsa dga* directfb* esd fbcon* opengl oss xinerama* xv -aalib* -arts* -ggi -libcaca -nas -noaudio -noflagstrip -nojoystick -novideo -pic -svga" 
[nomerge      ]              media-libs/mesa-6.5-r3  USE="motif nptl -debug -hardened%" VIDEO_CARDS="-i810 -mach64 -mga -none -r128 -radeon -s3virge -savage -sis -tdfx -trident -via" 
[nomerge      ]               app-admin/eselect-opengl-1.0.3  
[nomerge      ]                app-admin/eselect-1.0.2  USE="bash-completion doc" 
[ebuild     U ]                 sys-apps/file-4.17-r1 [4.13] USE="python -build" 543 kB 
[nomerge      ]              dev-lang/nasm-0.98.39-r3  USE="doc -build" 
[nomerge      ]               virtual/ghostscript-0  
[nomerge      ]                app-text/ghostscript-esp-8.15.1_p20060430  USE="X cups gtk xml -cjk -emacs -threads" 
[ebuild     U ]                 net-print/cups-1.1.23-r8 [1.1.23-r7] USE="nls pam ssl -gnutls -samba* -slp" 0 kB 
[nomerge      ]                  sys-libs/pam-0.78-r3  USE="berkdb -nis -pam_chroot -pam_console -pam_timestamp -pwdb" 
[ebuild     U ]                   sys-libs/cracklib-2.8.9 [2.8.5-r1] USE="nls python" 562 kB 
[nomerge      ]                 x11-libs/gtk+-2.8.12  USE="doc jpeg xinerama -debug -tiff" 
[nomerge      ]                  x11-libs/cairo-1.0.4  USE="X doc png -glitz" 
[ebuild     U ]                   media-libs/libpng-1.2.12 [1.2.8-r1] USE="doc" 606 kB 
[nomerge      ]                   virtual/xft-7.0  
[nomerge      ]                    x11-libs/libXft-2.1.10  USE="-debug" 
[nomerge      ]                     media-libs/fontconfig-2.2.3  
[ebuild     U ]                      media-libs/freetype-2.1.10-r2 [2.1.9-r1] USE="doc* zlib -bindist" 1,182 kB 
[ebuild     U ]                 media-libs/tiff-3.8.2-r1 [3.8.2] USE="jpeg zlib -jbig% -nocxx" 8 kB 
[ebuild     U ]           sys-fs/udev-087-r1 [087] 0 kB 
[ebuild     U ]            sys-apps/baselayout-1.11.15-r3 [1.11.14-r8] USE="unicode -bootstrap -build -static" 157 kB 
[ebuild     U ]             sys-apps/sysvinit-2.86-r5 [2.86-r3] USE="-bootstrap -build -static" 0 kB 
[ebuild     U ]         x11-libs/libX11-1.0.3 [1.0.1] USE="ipv6 -debug" 1,415 kB 
[ebuild     U ]          x11-libs/xtrans-1.0.1 [1.0.0] USE="-debug" 89 kB 
[nomerge      ]          x11-libs/libXau-1.0.1  USE="-debug" 
[ebuild     U ]           x11-proto/xproto-7.0.7 [7.0.5] USE="-debug" 130 kB 
[nomerge      ]          x11-proto/kbproto-1.0.2  USE="-debug" 
[ebuild     U ]           sys-devel/automake-1.9.6-r2 [1.9.6-r1] 0 kB 
[nomerge      ]            sys-devel/autoconf-2.59-r7  USE="-emacs" 
[ebuild     U ]             sys-devel/autoconf-wrapper-3.2 [3-r1] 0 kB 
[nomerge      ]     sys-apps/diffutils-2.8.7-r1  USE="nls -static" 
[nomerge      ]      sys-devel/gettext-0.14.4  USE="doc* nls -emacs" 
[ebuild     U ]       sys-libs/glibc-2.3.6-r4 [2.3.6-r3] USE="nls nptl -build -erandom -glibc-compat20 -glibc-omitfp -hardened -nptlonly -profile" 210 kB 
[nomerge      ] sys-devel/gcc-3.3.6  USE="doc% fortran gtk nls -bootstrap -boundschecking -build -gcj -hardened -ip28 -ip32r10k% -multislot -nocxx -nopie -nossp -objc -vanilla" 
[nomerge      ]        sys-devel/gcc-3.4.6-r1  USE="doc fortran gtk nls -bootstrap -boundschecking -build -gcj -hardened -ip28 -ip32r10k -multislot -nocxx -nopie -nossp -objc -vanilla" 
[ebuild     U ]         sys-devel/gcc-config-1.3.13-r3 [1.3.13-r2] 0 kB 
[ebuild     U ]         sys-devel/binutils-2.16.1-r3 [2.16.1-r2] USE="nls -multislot -multitarget -test -vanilla" 41 kB 

Total size of downloads: 292,987 kB

Re: [gentoo-dev] Re: Portage: missing pieces

[Richard Fish]

On 7/7/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
> > Are you using an portage overlay?  If so, what is in it?
>
> No.  No idea what that is.  Sounds interesting, though.

It is a local portage tree with ebuilds that you have either written
yourself or downloaded from others.  Since the overlay will override
what is in portage, you can easily get yourself into trouble this way.
 So it is not really recommended unless you *really* know what you are
doing!

> [nomerge      ] dev-util/mono-tools-1.1.11
> [ebuild  N    ]  dev-dotnet/gecko-sharp-0.6
> [nomerge      ]   www-client/mozilla-1.7.13

*Sigh*.  What a mess.  Unfortunately the Gentoo dev's have taken the
rather unusual step of _breaking the tree_ due to a security problem.
And from what I understand [1], mozilla is going to be package masked
today (if it hasn't already), so the block messages should go away,
but you'll get even worse "no package to satisify" messages.

At this point your choices are fairly limited, and neither one is very good.

1. Unmerge both mono-tools and gecko-sharp.  Mono-tools requires
gecko-sharp, and that requires mozilla.  You can use "equery files
mono-tools" to see what you will lose by going this route.

2. Manually unmask mozilla (and probably mono-tools and gecko-sharp)
to keep them around.  This might work, but I think you're going to be
jumping through a lot of hoops to try and avoid seamonkey.

-Richard

[1] http://bugs.gentoo.org/show_bug.cgi?id=137665
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Richard Fish writes:
> Unfortunately the Gentoo dev's have taken the rather unusual
> step of _breaking the tree_ due to a security problem.

Thanks for the info.

I would really wish that there was some mechanism in place to make
sure that the tree was never broken.

The current situation is very annoying for users that update often,
and also makes Portage mostly unusable for automatic server upgrades
:-(.

> 1. Unmerge both mono-tools and gecko-sharp.

That did the trick.
I'll have to remerge it later when/if the tree gets fixed...
Thanks!

(I see now that it was just me that didn't understand how to use
--tree, which makes much of this conversation off-topic... Sorry about
that!)

> [1] http://bugs.gentoo.org/show_bug.cgi?id=137665

I'm thinking that a Subversion pre-commit hook to secure integrity of
the Portage tree would be cool.  The changes listed in the bug above
would have to be committed atomically, or it wouldn't get through the
integrity check.  Perhaps there could be a staging area in the form of
a branch where the hypothetical integrity checker wouldn't run.  Ho
hum, wishful thinking.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Molle Bestefich wrote:
> The current situation is very annoying for users that update often,
> and also makes Portage mostly unusable for automatic server upgrades

After unmerging mono-tools so Portage could finally run a whole
update, it stopped halfway through because of this bug:
http://bugs.gentoo.org/show_bug.cgi?id=132122

I noticed that several users have commented with a relevant complaint:
GCC-4.x is required by the ebuild, but no information is ever conveyed
to the end user about this fact.  The ebuild does not have a
dependency on GCC-4.x.

Try reading the bug - users are basically being shoved off with an
arrogant silence and a stamp on their forehead saying INVALID.

Nothing personal against Jakub Moc who probably has a lot to do, but
the handling of relevant issues raised in the bugzilla is just
unacceptable.

What's the state of Portage and Gentoo in general?  Is there not
enough hands to do a proper job?  Or is it just that none of the devs
see what's wrong because bugs are wrongly being closed marked
"INVALID" such as the above when they're in fact not?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

Molle Bestefich wrote:
> I noticed that several users have commented with a relevant complaint:
> GCC-4.x is required by the ebuild, but no information is ever conveyed
> to the end user about this fact.  The ebuild does not have a
> dependency on GCC-4.x.

No, it's not. gcc-3.4.x *is* required. That versions (or later) is
*stable* everywhere where xine-lib is stable.


> Try reading the bug - users are basically being shoved off with an
> arrogant silence and a stamp on their forehead saying INVALID.
> 
> Nothing personal against Jakub Moc who probably has a lot to do, but
> the handling of relevant issues raised in the bugzilla is just
> unacceptable.

Dependency on a particular gcc version will solve exactly nothing.
Having that version installed doesn't mean you are really *using* it.
You won't be automagically switched to 3.4.x when upgrading from 3.3.x,
you won't be automatically switched to gcc 4.x when upgrading from 3.4.x

http://www.gentoo.org/doc/en/gcc-upgrading.xml

> What's the state of Portage and Gentoo in general?  Is there not
> enough hands to do a proper job?  Or is it just that none of the devs
> see what's wrong because bugs are wrongly being closed marked
> "INVALID" such as the above when they're in fact not?

How about the you finally upgrade your outdated gcc, as asked over and
over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing
any bugs there. Hard to understand? Apparently, I guess...

Thanks for your rant.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Portage: missing pieces

[Ciaran McCreesh]

On Sun, 09 Jul 2006 21:37:47 +0200 Jakub Moc <jakub@gentoo.org> wrote:
| Molle Bestefich wrote:
| > I noticed that several users have commented with a relevant
| > complaint: GCC-4.x is required by the ebuild, but no information is
| > ever conveyed to the end user about this fact.  The ebuild does not
| > have a dependency on GCC-4.x.
| 
| No, it's not. gcc-3.4.x *is* required. That versions (or later) is
| *stable* everywhere where xine-lib is stable.

Not true. According to the 2006.0 x86 profile, for example, you're
required to have ">=sys-devel/gcc-3.3.4-r1". There is no requirement
that 3.4 be installed.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

Ciaran McCreesh wrote:
> On Sun, 09 Jul 2006 21:37:47 +0200 Jakub Moc <jakub@gentoo.org> wrote:
> | Molle Bestefich wrote:
> | > I noticed that several users have commented with a relevant
> | > complaint: GCC-4.x is required by the ebuild, but no information is
> | > ever conveyed to the end user about this fact.  The ebuild does not
> | > have a dependency on GCC-4.x.
> | 
> | No, it's not. gcc-3.4.x *is* required. That versions (or later) is
> | *stable* everywhere where xine-lib is stable.
> 
> Not true. According to the 2006.0 x86 profile, for example, you're
> required to have ">=sys-devel/gcc-3.3.4-r1". There is no requirement
> that 3.4 be installed.
> 

Yeah, that's not what I've been talking about at all, what's your point?
I was saying that gcc-3.4 and better is stable everywhere where it's
needed. How does it change that 3.3 is dead as a nail in a lamproom door
 and users should switch to something that we actually can support?


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Portage: missing pieces

[Ciaran McCreesh]

On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc <jakub@gentoo.org> wrote:
| > Not true. According to the 2006.0 x86 profile, for example, you're
| > required to have ">=sys-devel/gcc-3.3.4-r1". There is no requirement
| > that 3.4 be installed.
| 
| Yeah, that's not what I've been talking about at all, what's your
| point? I was saying that gcc-3.4 and better is stable everywhere
| where it's needed. How does it change that 3.3 is dead as a nail in a
| lamproom door and users should switch to something that we actually
| can support?

Tradition for toolchain stuff has always been that anything allowed by
the profile is considered acceptable for general use. So, if users
shouldn't be using 3.3, the profile should be changed to say so. Until
then there's no obligation to upgrade.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Jakub Moc wrote:
> > Try reading the bug - users are basically being shoved off with an
> > arrogant silence and a stamp on their forehead saying INVALID.
> >
> > Nothing personal against Jakub Moc who probably has a lot to do, but
> > the handling of relevant issues raised in the bugzilla is just
> > unacceptable.
>
> Dependency on a particular gcc version will solve exactly nothing.
> Having that version installed doesn't mean you are really *using* it.
> You won't be automagically switched to 3.4.x when upgrading from 3.3.x,
> you won't be automatically switched to gcc 4.x when upgrading from 3.4.x

Yes ok.  So the user has to both merge the new version, and switch to it.

Either way, the end user is not getting told what should be done,
instead Portage just breaks, which is exactly what all the complaints
are about.

> How about the you finally upgrade your outdated gcc, as asked over and
> over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing
> any bugs there. Hard to understand? Apparently, I guess...

I've never been told so, I have no clue what you are talking about.

> Thanks for your rant.

What kind of reply do you expect to get from such crap?
Thanks for being an asshole?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Richard Fish]

On 7/9/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
>
> Try reading the bug - users are basically being shoved off with an
> arrogant silence and a stamp on their forehead saying INVALID.

*Sigh*.  You really should post to -user first.

The expectation here is that when a new version of gcc is stabilized,
that users will upgrade to that in a reasonable amount of time, and
use that (by selecting it with gcc-config) for compiling all new
updates.  FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the
current stable is 3.4.6-r1 since May 29th.

The devs can *not* be expected to verify that all software in portage
builds with all versions of gcc in portage.  For example, there is
still an ebuild for gcc-2.95.3!  But that is _not_ to be used for
compiling new updates.

The alternative here is that old versions of gcc disappear from
portage, but that causes a problem for those who need those versions
for some reason, such as compiling non-gentoo software.

> Nothing personal against Jakub Moc who probably has a lot to do, but
> the handling of relevant issues raised in the bugzilla is just
> unacceptable.

What, exactly, do you find unacceptable in "Your gcc version is
outdated and unsupported"?

I suppose portage could be enhanced to have a
is_gcc_version_supported() check, but I'm not sure how useful that
would be.

> What's the state of Portage and Gentoo in general?  Is there not
> enough hands to do a proper job?  Or is it just that none of the devs
> see what's wrong because bugs are wrongly being closed marked
> "INVALID" such as the above when they're in fact not?

If you want to test compiling every version of every package in
portage with all 21 versions (16 if you assume all -rX versions are
compatible, or /only 9/ if you only consider stable x86 versions) of
gcc that are currently in portage, and submit patches when things
fail, go ahead.  BTW, your patches cannot remove the ability to use
improvements that are only available in newer stable versions of gcc,
such as -fvisibility=hidden.

-Richard
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Richard Fish wrote:
> The expectation here is that when a new version of gcc is stabilized,
> that users will upgrade to that in a reasonable amount of time, and
> use that (by selecting it with gcc-config) for compiling all new
> updates.  FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the
> current stable is 3.4.6-r1 since May 29th.

I don't see how that information is conveyed to the user.  Portage
shouts about upgrading to a new profile from time to time, but it
never tells anyone to upgrade GCC.  Perhaps it should, if that's what
the devs expect people to do.

> The devs can *not* be expected to verify that all software in portage
> builds with all versions of gcc in portage.

Of course not.

> The alternative here is that old versions of gcc disappear from
> portage, but that causes a problem for those who need those versions
> for some reason, such as compiling non-gentoo software.

Yes, ok.  That's a bad alternative.  Thus it seems that there's no
appropriate mechanism to handle new GCC versions in Portage, which
again makes sense wrt. the complaints.

> > Nothing personal against Jakub Moc who probably has a lot to do, but
> > the handling of relevant issues raised in the bugzilla is just
> > unacceptable.
>
> What, exactly, do you find unacceptable in
> "Your gcc version is outdated and unsupported"?

Nothing?
I find it unacceptable that the bug is marked INVALID when it clearly
describes a relevant issue.

As far as I can tell, the complaints are about Portage being unable to
handle GCC upgrades gracefully for end users.

You could perhaps argue that the issue started out as "why do I get
this error message" and ended up being "why doesn't Portage handle GCC
upgrades gracefully", which is of course a slightly different thing.
But it should be clear to anyone reading the bug what the real issue
is.  I'm even willing to bet that if I create a new bug describing the
Portage issue, with no mention of the specific xine ebuild, it will
get closed as a duplicate of this bug anyway.  I've got case studies
proving that this is what happens, heh.

> I suppose portage could be enhanced to have a is_gcc_version_supported()
> check, but I'm not sure how useful that would be.

If that would enable ebuild maintainers to flag xine as requiring 3.4
for compilation, then that would definitely solve the issue described
in the bug.  I'd say that's _very useful_ to the end user.

You could argue that only a couple of people has spent the time to
create a bugzilla login and lodge a complaint in the bug, but there's
probably more out there.  We can count the duplicates in a couple of
months and see ;-).  And as newer GCC features are used throughout,
the situation will probably happen more in the future.

> > What's the state of Portage and Gentoo in general?  Is there not
> > enough hands to do a proper job?  Or is it just that none of the devs
> > see what's wrong because bugs are wrongly being closed marked
> > "INVALID" such as the above when they're in fact not?
>
> If you want to test compiling every version of every package in
> portage with all 21 versions (16 if you assume all -rX versions are
> compatible, or /only 9/ if you only consider stable x86 versions) of
> gcc that are currently in portage, and submit patches when things
> fail, go ahead.

That won't be necessary.  Things mostly works, and when they don't,
users file a bug like the aforementioned one, which should result in
that particular ebuild getting fixed, instead of the bug being marked
INVALID.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Josh Saddler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc <jakub@gentoo.org> wrote:
> | > Not true. According to the 2006.0 x86 profile, for example, you're
> | > required to have ">=sys-devel/gcc-3.3.4-r1". There is no requirement
> | > that 3.4 be installed.
> | 
> | Yeah, that's not what I've been talking about at all, what's your
> | point? I was saying that gcc-3.4 and better is stable everywhere
> | where it's needed. How does it change that 3.3 is dead as a nail in a
> | lamproom door and users should switch to something that we actually
> | can support?
> 
> Tradition for toolchain stuff has always been that anything allowed by
> the profile is considered acceptable for general use. So, if users
> shouldn't be using 3.3, the profile should be changed to say so. Until
> then there's no obligation to upgrade.
> 

Then it seems like that 2006.0 x86 profile should be updated (without waiting
for 2006.1 to be released). Dunno if other arches have to run such legacy gcc
versions, but the logical thing is to point to 3.4.x instead on x86.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEsYLBrsJQqN81j74RAidcAKCGdhpAiObclSZuwR8Heod1wqK9yQCgmI16
ax6u8GA7z9GQEkdqErq8xD4=
=0VzK
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 6522 bytes --]

On Sun, 9 Jul 2006 23:30:40 +0200
"Molle Bestefich" <molle.bestefich@gmail.com> wrote:

> Richard Fish wrote:
> > The expectation here is that when a new version of gcc is
> > stabilized, that users will upgrade to that in a reasonable amount
> > of time, and use that (by selecting it with gcc-config) for
> > compiling all new updates.  FYI, gcc-3.4.4-r1 was stabilized on
> > 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th.
> 
> I don't see how that information is conveyed to the user.

It's conveyed by the fact that when updating, you see a new compiler
version being installed.  If you have done a world update, you already
have the later compilers installed.

>  Portage
> shouts about upgrading to a new profile from time to time, but it
> never tells anyone to upgrade GCC.  Perhaps it should, if that's what
> the devs expect people to do.

As has been explained before, as far as the gcc ebuilds are concerned
their job is finished when the new compiler version is installed.  It
is up to the user to decide to change their system compiler.  The
gcc ebuild will switch between minor versions if USE=multislot isn't
specified, and in that case will warn the user about ABI breakage if
relevant, as it requires the user to rebuild lots of stuff.

> > The devs can *not* be expected to verify that all software in
> > portage builds with all versions of gcc in portage.
> 
> Of course not.
> 
> > The alternative here is that old versions of gcc disappear from
> > portage, but that causes a problem for those who need those versions
> > for some reason, such as compiling non-gentoo software.
> 
> Yes, ok.  That's a bad alternative.  Thus it seems that there's no
> appropriate mechanism to handle new GCC versions in Portage, which
> again makes sense wrt. the complaints.

Portage and the ebuilds handle it fine.  All that needs to happen is
for users to accept the advice to read the gcc upgrading guide when
they trip over problems that arise from issues with gcc versions.

> > > Nothing personal against Jakub Moc who probably has a lot to do,
> > > but the handling of relevant issues raised in the bugzilla is just
> > > unacceptable.
> >
> > What, exactly, do you find unacceptable in
> > "Your gcc version is outdated and unsupported"?
> 
> Nothing?
> I find it unacceptable that the bug is marked INVALID when it clearly
> describes a relevant issue.

Don't take the bug marking as a personal attack - it's a marking for
devs to understand what was the impact of the bug.  Focus on the advice
given, which from what I can see was succinct and correct.

> As far as I can tell, the complaints are about Portage being unable to
> handle GCC upgrades gracefully for end users.

What exactly do you expect to happen?  GCC updates don't switch major
versions automatically, because in general it means changing ABI which
means rebuilding everything.  Where ABI breakage occurs between minor
versions and the compiler is switched automatically, the ebuild issues
a warning when ABI breakage occurs and advises what to do to rebuild
affected packages.

> You could perhaps argue that the issue started out as "why do I get
> this error message" and ended up being "why doesn't Portage handle GCC
> upgrades gracefully", which is of course a slightly different thing.
> But it should be clear to anyone reading the bug what the real issue
> is.  I'm even willing to bet that if I create a new bug describing the
> Portage issue, with no mention of the specific xine ebuild, it will
> get closed as a duplicate of this bug anyway.  I've got case studies
> proving that this is what happens, heh.

If two bugs describe the same issue, regardless of the summary field
one will get marked as a duplicate of the other.  Again, this is not a
personal attack but information for devs to understand whether
different work is needed for the different bugs.

> > I suppose portage could be enhanced to have a
> > is_gcc_version_supported() check, but I'm not sure how useful that
> > would be.
> 
> If that would enable ebuild maintainers to flag xine as requiring 3.4
> for compilation, then that would definitely solve the issue described
> in the bug.  I'd say that's _very useful_ to the end user.

The problem with having the xine ebuild check gcc version and aborting
if a certain version is found active, is that if the gcc version is
modified in the future such that xine would then build with it, that
handling would have to come out again.  Since the ebuild dies either
way, the only difference is that some users may not realise that
upgrading gcc will work - in which case they file a bug and they get
told to upgrade gcc - job done.

> You could argue that only a couple of people has spent the time to
> create a bugzilla login and lodge a complaint in the bug, but there's
> probably more out there.  We can count the duplicates in a couple of
> months and see ;-).  And as newer GCC features are used throughout,
> the situation will probably happen more in the future.

Another way of looking at it, is that there are a lot of people out
there who are coping just fine with GCC upgrades as they are currently
managed.

> > > What's the state of Portage and Gentoo in general?  Is there not
> > > enough hands to do a proper job?  Or is it just that none of the
> > > devs see what's wrong because bugs are wrongly being closed marked
> > > "INVALID" such as the above when they're in fact not?
> >
> > If you want to test compiling every version of every package in
> > portage with all 21 versions (16 if you assume all -rX versions are
> > compatible, or /only 9/ if you only consider stable x86 versions) of
> > gcc that are currently in portage, and submit patches when things
> > fail, go ahead.
> 
> That won't be necessary.  Things mostly works, and when they don't,
> users file a bug like the aforementioned one, which should result in
> that particular ebuild getting fixed, instead of the bug being marked
> INVALID.

As I said above, don't take the "INVALID" marking personally.  The fact
is that from the perspective of the relevant devs, the resolution of the
bug was to advise the user to upgrade gcc, which meant no change
required to the tree. See
https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs are
concerned, "The problem described is not a bug" so INVALID is the
correct resolution marking.


-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Portage: missing pieces

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On Sun, 09 Jul 2006 15:27:14 -0700
Josh Saddler <nightmorph@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ciaran McCreesh wrote:
> > On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc <jakub@gentoo.org>
> > wrote: | > Not true. According to the 2006.0 x86 profile, for
> > example, you're | > required to have ">=sys-devel/gcc-3.3.4-r1".
> > There is no requirement | > that 3.4 be installed.
> > | 
> > | Yeah, that's not what I've been talking about at all, what's your
> > | point? I was saying that gcc-3.4 and better is stable everywhere
> > | where it's needed. How does it change that 3.3 is dead as a nail
> > in a | lamproom door and users should switch to something that we
> > actually | can support?
> > 
> > Tradition for toolchain stuff has always been that anything allowed
> > by the profile is considered acceptable for general use. So, if
> > users shouldn't be using 3.3, the profile should be changed to say
> > so. Until then there's no obligation to upgrade.
> > 
> Then it seems like that 2006.0 x86 profile should be updated (without
> waiting for 2006.1 to be released). Dunno if other arches have to run
> such legacy gcc versions, but the logical thing is to point to 3.4.x
> instead on x86.

I don't believe retro-actively modifying the 2006.0 profile is a good
idea in general. The profile currently says that for x86, gcc
must be ">=sys-devel/gcc-3.3.4-r1" - if you do

# emerge >=sys-devel/gcc-3.3.4-r1

on a current tree you'll get a much higher version.  Still, it's up to
releng if they wish to change it.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Portage: missing pieces

[Andrew Gaffney]

Kevin F. Quinn wrote:
> I don't believe retro-actively modifying the 2006.0 profile is a good
> idea in general. The profile currently says that for x86, gcc
> must be ">=sys-devel/gcc-3.3.4-r1" - if you do
> 
> # emerge >=sys-devel/gcc-3.3.4-r1
> 
> on a current tree you'll get a much higher version.  Still, it's up to
> releng if they wish to change it.

Even if you modify the profile to "mask" gcc-3.3.x, it won't force people to 
unmerge their existing gcc-3.3.x since it's slotted and they would already have 
gcc-3.4.x emerged, correct? And if we can't force them to unmerge it, we can't 
force them to switch which gcc version is active. Masking in the profile would 
have no effect if this is true.

-- 
Andrew Gaffney                            http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer                                   Installer Project
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Richard Fish]

On 7/9/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
> As far as I can tell, the complaints are about Portage being unable to
> handle GCC upgrades gracefully for end users.

The thing is, that portage doesn't technically "handle" gcc upgrades.
The user really needs to do that, and they (should) know to do that
when they see the new version show up in an "emerge -Duv world".  Or
on GWN.

Ok, so some users are not getting that message.  To be honest, I have
no idea what to do about that.  Having dozens (hundreds?  all?)
ebuilds check for a minimum version of gcc doesn't seem very
effecient.  I guess portage could check and warn about an unsupported
version of gcc being selected for the system compiler, but then I we
have to figure out exactly what the "supported" versions are, and
exactly when a version becomes unsupported, as a matter of policy.

But that won't even fix the "problem".  The version of xine-lib that
this bug refers to is a ~x86 version.  Should that be expected to
compile with the stable gcc?  Or only with the ~x86 gcc.  What if the
maintainer doesn't intend to stabilize the package until the ~x86
version of gcc goes stable?

So I don't think the issue is as simple as either having xine-lib put
out a warning about a particular gcc version, as that doesn't work in
the general case.  And putting the checks in portage doesn't seem to
work very well either.

The system as it is now actually seems to work about right...the vast
majority of stable users upgrade to new versions of gcc as they come
out, hopefully following the upgrade guide, and never see anything
fail to build due to the gcc version.  Others get informed via other
means, and hopefully remember for the future.

> That won't be necessary.  Things mostly works, and when they don't,
> users file a bug like the aforementioned one, which should result in
> that particular ebuild getting fixed, instead of the bug being marked
> INVALID.

The thing is, "this particular ebuild" isn't actually broken.  Or I
guess if it is, then so are <some_potentially_large_number> other
ebuilds in the tree, since they probably won't build with old gcc
versions either.  Ok, most would probably build with gcc 3.3.  And
maybe even gcc 3.1.  But 2.95??  Handling this at the ebuild level is
just not a good solution for the general case.

-Richard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

Richard Fish wrote:
>> That won't be necessary.  Things mostly works, and when they don't,
>> users file a bug like the aforementioned one, which should result in
>> that particular ebuild getting fixed, instead of the bug being marked
>> INVALID.
> 
> The thing is, "this particular ebuild" isn't actually broken.  Or I
> guess if it is, then so are <some_potentially_large_number> other
> ebuilds in the tree, since they probably won't build with old gcc
> versions either.  Ok, most would probably build with gcc 3.3.  And
> maybe even gcc 3.1.  But 2.95??  Handling this at the ebuild level is
> just not a good solution for the general case.
> 
> -Richard

Well yeah, there's nothing broken w/ the ebuild. And xine-lib is _not_
the only thing that just bombs out on sucky compiler version, see fex.
http://bugs.gentoo.org/show_bug.cgi?id=121501

There's no sane way to force users to switch their gcc version, so
messing w/ ebuild deps, profiles or keywords of outdated gcc versions
won't help...



-- 

jakub



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Portage: missing pieces

[Ciaran McCreesh]

On Mon, 10 Jul 2006 01:18:07 -0500 Andrew Gaffney <agaffney@gentoo.org>
wrote:
| Even if you modify the profile to "mask" gcc-3.3.x, it won't force
| people to unmerge their existing gcc-3.3.x since it's slotted and
| they would already have gcc-3.4.x emerged, correct? And if we can't
| force them to unmerge it, we can't force them to switch which gcc
| version is active. Masking in the profile would have no effect if
| this is true.

Yeah. It's more of a tradition thing than a strict technological
enforcement. In the past we've always considered any GCC allowed by the
profile (that is to say, not masked or out of the packages range) to be
valid. Refusing to take bugs from people who're using a GCC permitted
by the profile is rather unfair...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Ciaran McCreesh]

On Mon, 10 Jul 2006 10:41:25 +0200 Jakub Moc <jakub@gentoo.org> wrote:
| There's no sane way to force users to switch their gcc version, so
| messing w/ ebuild deps, profiles or keywords of outdated gcc versions
| won't help...

Messing with profiles will, however, give you grounds to close bugs as
INVALID.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Kevin F. Quinn wrote:
> > > The expectation here is that when a new version of gcc is
> > > stabilized, that users will upgrade to that in a reasonable amount
> > > of time, and use that (by selecting it with gcc-config) for
> > > compiling all new updates.  FYI, gcc-3.4.4-r1 was stabilized on
> > > 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th.
> >
> > I don't see how that information is conveyed to the user.
>
> It's conveyed by the fact that when updating, you see a new compiler
> version being installed.  If you have done a world update, you
> already have the later compilers installed.

No, that's not true.  It's not conveyed at all.
It might install a new GCC, but it doesn't switch to it.
It doesn't tell the user to switch to it, either.

> As has been explained before, as far as the gcc ebuilds are
> concerned their job is finished when the new compiler version
> is installed.  It is up to the user to decide to change their
> system compiler.

You seem to have missed the issue.

> > Yes, ok.  That's a bad alternative.  Thus it seems that there's no
> > appropriate mechanism to handle new GCC versions in Portage, which
> > again makes sense wrt. the complaints.
>
> Portage and the ebuilds handle it fine.

Same.

> All that needs to happen is for users to accept the advice to read
> the gcc upgrading guide when they trip over problems that arise
> from issues with gcc versions.

There's no advice, instead Portage crashes during a system update.

> > Nothing?
> > I find it unacceptable that the bug is marked INVALID when it clearly
> > describes a relevant issue.
>
> Don't take the bug marking as a personal attack

I don't, it's not my bug ;-).

> it's a marking for devs to understand what was the impact of the bug.

It's marked INVALID, while the issue is clearly valid.

> Focus on the advice given, which from what I can see was succinct
> and correct.

It shouldn't even be _necessary_ to create bugs and receive advice
from a living, breathing human being just to perform a system update.

> > As far as I can tell, the complaints are about Portage being unable to
> > handle GCC upgrades gracefully for end users.
>
> What exactly do you expect to happen?  GCC updates don't switch major
> versions automatically, because in general it means changing ABI which
> means rebuilding everything.

Ah, that's a good question.

I think the proper reaction from Portage would be (both):
 a) Alert the user that the newest version of package XYZ cannot be
    merged because it needs a newer compiler than the currently
    selected one.
 b) Skip package XYZ, but continue updating the rest of the system.

Package XYZ could also block the update, that would be OK.

> Again, this is not a personal attack but information for devs
> to understand whether different work is needed for the different bugs.

Noone has mentioned personal attacks, so drop that train of thought.

You misread my point.  I was trying to say that bugs describing problems
(with fx. Portage) in abstract will often get closed as a duplicate of a
bug where someone has experienced a particular incarnation of the
larger problem described.

That's a good way to make sure that relevant end user issues never
come into contact with the devs, which I'm sure is not what the
devs want.

> > > I suppose portage could be enhanced to have a
> > > is_gcc_version_supported() check, but I'm not sure how useful that
> > > would be.
> >
> > If that would enable ebuild maintainers to flag xine as requiring 3.4
> > for compilation, then that would definitely solve the issue described
> > in the bug.  I'd say that's _very useful_ to the end user.
>
> The problem with having the xine ebuild check gcc version and aborting
> if a certain version is found active,

I don't think anyone would implement it that way, since that's braindead ;-).
Instead of checking a particular version, checking for a minimum
version would be the default available functionality.

> is that if the gcc version is modified in the future such that xine would
> then build with it, that handling would have to come out again.

In the (hysterically abstract) situation where someone revisits an old
version of GCC and adds GCC-4 features, nothing would break.

Users would still be told to upgrade to a newer version, and all would
be well, despite the fact that the old GCC with the backported feature
could now theoretically be used.

(But it's just trolling anyway, you're really describing a non-issue, IMHO.)

> Another way of looking at it, is that there are a lot of people out
> there who are coping just fine with GCC upgrades as they are currently
> managed.

Uh.  What's your point?
That you're one of those people who hates change just because it's
change, or do you have something more relevant to say that I'm not
catching?

> See https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs
> are concerned, "The problem described is not a bug" so INVALID is the
> correct resolution marking.

"Not a bug" does not translate to "Not an issue".
You're practicing an extremely narrow view of what's a bug, and that's
fine - we'll just call it an issue instead.
Next step is to either
 a) declare that the Gentoo Bugzilla is in fact an issue tracker, or
 b) decide that problems which does not fit your narrow view of a
"bug" belongs on a mailing list.

Either way is fine, someone just needs to decide where more abstract
issues should be archived - in the bugzilla or in the mailing
list(s)'s archives.

In case of b), fields.html should be modified to
 1) include your narrow view of what's-a-bug-and-what's-not (see
INVALID), the current description doesn't do.
 2) tell people to take problems which doesn't fit that view to the
mailing list(s).

A good place to end this bug-or-not branch of the discussion which
you've delved into would IMHO be if you could create a good
description/explanation to use with bullet 1).  I know it's not easy,
which is probably why most people go with something like solution a,
heh, but I'm sure it can be done with some hard thinking.  It seems to
me that that's the only way to actually validate your point.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Richard Fish wrote:
> Having dozens (hundreds?  all?) ebuilds check for a minimum version

Probably just the ebuilds that happen to use new GCC features before
the mass of the general public has changed to that version.  But yes,
a minimum version constraint could theoretically end up in a lot of
packages.

> of gcc doesn't seem very effecient.

I can't see why it would not be efficient?

> I don't think the issue is as simple as either having xine-lib put
> out a warning about a particular gcc version, as that doesn't work
> in the general case.

Obviously any solution implemented should work for all ebuilds, not
just xine-lib.

> And putting the checks in portage doesn't seem to work very well
> either.

I fail to see how a test in the ebuild for the active
GCC compiler version wouldn't work?

> The system as it is now actually seems to work about right... the
> vast majority of stable users upgrade to new versions of gcc as they
> come out

Really?
How do you gather?
I'd think that most users hadn't even run into this problem (yet),
because many source code maintainers strive to be able to compile with
as old a version of GCC as possible..
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

Molle Bestefich wrote:
> Kevin F. Quinn wrote:
>> > > The expectation here is that when a new version of gcc is
>> > > stabilized, that users will upgrade to that in a reasonable amount
>> > > of time, and use that (by selecting it with gcc-config) for
>> > > compiling all new updates.  FYI, gcc-3.4.4-r1 was stabilized on
>> > > 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th.
>> >
>> > I don't see how that information is conveyed to the user.
>>
>> It's conveyed by the fact that when updating, you see a new compiler
>> version being installed.  If you have done a world update, you
>> already have the later compilers installed.
> 
> No, that's not true.  It's not conveyed at all.
> It might install a new GCC, but it doesn't switch to it.

Sigh. Because it would break your system!

> It doesn't tell the user to switch to it, either.

You really need to research better if you insist on beating a dead horse
over and over again. Kindly read the toolchain.eclass:

<snip>
einfo "You should make sure to rebuild all your C++ packages when"
einfo "upgrading between different versions of gcc.  For example,"
einfo "when moving to gcc-3.4 from gcc-3.3, emerge gentoolkit and run:"
einfo "  # revdep-rebuild --library libstdc++.so.5"
echo
einfo "For more information on the steps to take when upgrading "
einfo "from gcc-3.3 please refer to: "
einfo "http://www.gentoo.org/doc/en/gcc-upgrading.xml"
echo
</snip>


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Jakub Moc wrote:
> Sigh. Because it would break your system!
>
> You really need to research better if you insist on beating a dead
> horse over and over again. Kindly read the toolchain.eclass:

You're misreading me.

I was merely counter-arguing Kevin, who said that Portage provides
plenty of information to the end user about GCC switches being
necessary.

I was not trying to convince anyone to make Portage switch GCC
version automatically.  That would probably be rather insane.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 10915 bytes --]

On Mon, 10 Jul 2006 19:23:54 +0200
"Molle Bestefich" <molle.bestefich@gmail.com> wrote:

> Kevin F. Quinn wrote:
> > > > The expectation here is that when a new version of gcc is
> > > > stabilized, that users will upgrade to that in a reasonable
> > > > amount of time, and use that (by selecting it with gcc-config)
> > > > for compiling all new updates.  FYI, gcc-3.4.4-r1 was
> > > > stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1
> > > > since May 29th.
> > >
> > > I don't see how that information is conveyed to the user.
> >
> > It's conveyed by the fact that when updating, you see a new compiler
> > version being installed.  If you have done a world update, you
> > already have the later compilers installed.
> 
> No, that's not true.  It's not conveyed at all.

It is clear that a new version of GCC is installed.  It is also clear
that it is not switched to (otherwise the upgrade would have to trundle
off and rebuild everything - we'd be swamped with complaints if we did
that!).

> It might install a new GCC, but it doesn't switch to it.

By design.

> It doesn't tell the user to switch to it, either.

Again by design.

It's up to the user to switch to a different compiler, should they wish
to.  In other words, it's a user choice which compiler version they use.

> > As has been explained before, as far as the gcc ebuilds are
> > concerned their job is finished when the new compiler version
> > is installed.  It is up to the user to decide to change their
> > system compiler.
> 
> You seem to have missed the issue.

Maybe, that wasn't my point.  I'm telling you what the situation re.
compiler installation actually is, and how it is designed to be.


> > > Yes, ok.  That's a bad alternative.  Thus it seems that there's no
> > > appropriate mechanism to handle new GCC versions in Portage, which
> > > again makes sense wrt. the complaints.
> >
> > Portage and the ebuilds handle it fine.
> 
> Same.
> 
> > All that needs to happen is for users to accept the advice to read
> > the gcc upgrading guide when they trip over problems that arise
> > from issues with gcc versions.
> 
> There's no advice, instead Portage crashes during a system update.

The advice is to switch to a more recent compiler.  Jakub has made that
clear on the bug, and we've said it several times here.  As a result,
there is no change to be done to any ebuilds etc.


> > > Nothing?
> > > I find it unacceptable that the bug is marked INVALID when it
> > > clearly describes a relevant issue.
> >
> > Don't take the bug marking as a personal attack
> 
> I don't, it's not my bug ;-).
> 
> > it's a marking for devs to understand what was the impact of the
> > bug.
> 
> It's marked INVALID, while the issue is clearly valid.

OK; one more time.  The bug does not lead to any change to anything in
the tree.  Therefore it is marked INVALID, in that it is not a valid
issue with respect to the Gentoo tree.  INVALID has the meaning
ascribed to it on the bugzilla help page, not the meaning from an
English dictionary.  When a bug is fixed, something has to change for
that fix to happen - if there's no change, either there's a
bug that we won't fix (WONTFIX) or there's no bug.  In this case
there's no bug, in my opinion.

> > Focus on the advice given, which from what I can see was succinct
> > and correct.
> 
> It shouldn't even be _necessary_ to create bugs and receive advice
> from a living, breathing human being just to perform a system update.

You have to realise that being a constantly moving source distribution,
it is impossible to ensure that all packages in all stable versions
interoperate in all possible combinations.  We don't guarantee that.
We do go to some effort to ensure all latest stable versions
interoperate when built sensibly, when it comes to a release - that's as
far as we can go, realistically.


> > > As far as I can tell, the complaints are about Portage being
> > > unable to handle GCC upgrades gracefully for end users.
> >
> > What exactly do you expect to happen?  GCC updates don't switch
> > major versions automatically, because in general it means changing
> > ABI which means rebuilding everything.
> 
> Ah, that's a good question.
> 
> I think the proper reaction from Portage would be (both):
>  a) Alert the user that the newest version of package XYZ cannot be
>     merged because it needs a newer compiler than the currently
>     selected one.

I explained above why this wouldn't be a good idea.

>  b) Skip package XYZ, but continue updating the rest of the system.

emerge --resume --skipfirst

> Package XYZ could also block the update, that would be OK.

The problem with this is the same as with (a).

> > Again, this is not a personal attack but information for devs
> > to understand whether different work is needed for the different
> > bugs.
> 
> Noone has mentioned personal attacks, so drop that train of thought.
> 
> You misread my point.  I was trying to say that bugs describing
> problems (with fx. Portage) in abstract will often get closed as a
> duplicate of a bug where someone has experienced a particular
> incarnation of the larger problem described.

(Just to clarify - "portage" refers to the application
sys-apps/portage, which you use to install stuff from the tree of
ebuilds, often referred to as the "portage tree")

> That's a good way to make sure that relevant end user issues never
> come into contact with the devs, which I'm sure is not what the
> devs want.

When a bug is marked as a duplicate, a comment is added automatically
to that bug indicating which bug it is being marked a duplicate of.
Also, the reporter of the duplicate bug is added to the CC list of the
original bug.  In this way, the reporter is integrated into the
communication chain for the original bug, where they can read back
through the history, comment, receive bug data from devs actioning the
bug etc.  So your point 


> > > > I suppose portage could be enhanced to have a
> > > > is_gcc_version_supported() check, but I'm not sure how useful
> > > > that would be.
> > >
> > > If that would enable ebuild maintainers to flag xine as requiring
> > > 3.4 for compilation, then that would definitely solve the issue
> > > described in the bug.  I'd say that's _very useful_ to the end
> > > user.
> >
> > The problem with having the xine ebuild check gcc version and
> > aborting if a certain version is found active,
> 
> I don't think anyone would implement it that way, since that's
> braindead ;-). Instead of checking a particular version, checking for
> a minimum version would be the default available functionality.
> 
> > is that if the gcc version is modified in the future such that xine
> > would then build with it, that handling would have to come out
> > again.
> 
> In the (hysterically abstract) situation where someone revisits an old
> version of GCC and adds GCC-4 features, nothing would break.

You would be surprised; fixes from later versions are often back-ported
to older versions (especially when upstream do so).


> Users would still be told to upgrade to a newer version, and all would
> be well, despite the fact that the old GCC with the backported feature
> could now theoretically be used.
> 
> (But it's just trolling anyway, you're really describing a non-issue,
> IMHO.)
> 
> > Another way of looking at it, is that there are a lot of people out
> > there who are coping just fine with GCC upgrades as they are
> > currently managed.
> 
> Uh.  What's your point?
> That you're one of those people who hates change just because it's
> change, or do you have something more relevant to say that I'm not
> catching?

My point is that you imply this issue is a problem for many users - a
point you snipped so I'm pasting it again here:

> You could argue that only a couple of people has spent the time to
> create a bugzilla login and lodge a complaint in the bug, but there's
> probably more out there.  We can count the duplicates in a couple of
> months and see ;-).  And as newer GCC features are used throughout,
> the situation will probably happen more in the future.

My point is that from what we can see, it isn't a problem for many
users.

> > See https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs
> > are concerned, "The problem described is not a bug" so INVALID is
> > the correct resolution marking.
> 
> "Not a bug" does not translate to "Not an issue".
> You're practicing an extremely narrow view of what's a bug, and that's
> fine - we'll just call it an issue instead.
> Next step is to either
>  a) declare that the Gentoo Bugzilla is in fact an issue tracker, or
>  b) decide that problems which does not fit your narrow view of a
> "bug" belongs on a mailing list.

We consider bug and issue to be the same thing, as far as Gentoo
Bugzilla is concerned.  Gentoo bugzilla is there to track any problem
a user might have with Gentoo.  Clearly there are times when the user
just has to follow some simple instructions to sort out their system
without any change needed to the tree.  In these cases we mark the
bugs FIXED/INVALID.  My point is that the bug is resolved without
needing any change to the portage tree - therefore it is marked
INVALID.  Whether you call the reports bugs, issues, tickets whatever is
irrelevant.

> Either way is fine, someone just needs to decide where more abstract
> issues should be archived - in the bugzilla or in the mailing
> list(s)'s archives.

We track all issues in Gentoo Bugzilla, be they bugs, enhancement
requests, whatever.  Many times a bug is raised that is resolved
without needing any change to the tree - in that case we mark it
RESOLVED/INVALID.  If we wanted to be warm and fuzzy about it, we could
change the INVALID to NOT-A-BUG (which is what GNU do) or perhaps if we
want to be really cuddly we could try "NOCHANGE".  Personally I don't
think it's worth the effort.

> In case of b), fields.html should be modified to
>  1) include your narrow view of what's-a-bug-and-what's-not (see
> INVALID), the current description doesn't do.
>  2) tell people to take problems which doesn't fit that view to the
> mailing list(s).
> 
> A good place to end this bug-or-not branch of the discussion which
> you've delved into would IMHO be if you could create a good
> description/explanation to use with bullet 1).  I know it's not easy,
> which is probably why most people go with something like solution a,
> heh, but I'm sure it can be done with some hard thinking.  It seems to
> me that that's the only way to actually validate your point.

A good place to end it is here, because it is of no value to pursue it
further.


-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Portage: missing pieces

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On Mon, 10 Jul 2006 19:32:00 +0200
"Molle Bestefich" <molle.bestefich@gmail.com> wrote:

> Richard Fish wrote:
> > Having dozens (hundreds?  all?) ebuilds check for a minimum version
> 
> Probably just the ebuilds that happen to use new GCC features before
> the mass of the general public has changed to that version.  But yes,
> a minimum version constraint could theoretically end up in a lot of
> packages.
> 
> > of gcc doesn't seem very effecient.
> 
> I can't see why it would not be efficient?

Imagine checking over 11,000 packages (over 24,000 ebuilds) against all
stable compiler versions in the tree, working out which versions of the
compiler currently don't allow each package to build successfully and
then adding the relevant code to the ebuild to handle that information.

Now imagine updating a compiler version to fix an issue, then having to
go through the whole tree looking for ebuilds that restrict against
that compiler version, and checking them to see if the restriction can
be lifted.

It may be efficient for the user, but it creates mountains of work for
the volunteer devs whose time is better spent focusing on latest stable
versions.

> 
> > I don't think the issue is as simple as either having xine-lib put
> > out a warning about a particular gcc version, as that doesn't work
> > in the general case.
> 
> Obviously any solution implemented should work for all ebuilds, not
> just xine-lib.
> 
> > And putting the checks in portage doesn't seem to work very well
> > either.
> 
> I fail to see how a test in the ebuild for the active
> GCC compiler version wouldn't work?

It wouldn't work in that it's just not maintainable.  There's more to a
process working than just whether a particular piece of code functions
correctly or not.

> > The system as it is now actually seems to work about right... the
> > vast majority of stable users upgrade to new versions of gcc as they
> > come out
> 
> Really?
> How do you gather?

Suffice to say that many users track the latest stable versions of
everything on their system.  We don't know how many people stick to old
versions or for how long they do so.  However if many people remained
on old versions of the compiler, I suspect we'd be seeing a lot of bugs
related to that - and we're not seeing them.

> I'd think that most users hadn't even run into this problem (yet),
> because many source code maintainers strive to be able to compile with
> as old a version of GCC as possible..

That's unlikely to be true.  Some upstream developers do maintain
compatibility with a range of compiler versions.  Some upstream
developers only recommend one specific version.  Many will be somewhere
in between.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Portage: missing pieces

[Richard Fish]

On 7/10/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
> Richard Fish wrote:
> > of gcc doesn't seem very effecient.
>
> I can't see why it would not be efficient?

I think it is an inefficient use of developer time.  Do we really want
gentoo devs spending their time figuring out what the minimum gcc
version is for their packages, and then having very similar code
duplicated in every ebuild in the tree?  Is the problem really so
serious that it requires that much effort?

I am not saying that there should never be a check for a minimum gcc
version...maybe if a large enough population of users is having a
problem with a particular package because of gcc, then that package
_should_ have a check with an appropriate "stop using obsolete gcc
versions" message.  But it should only be done in response to bug
filings, and at the discretion of the package maintainer.

And let's remember that this is a ~arch package.  The expectations of
people using ~arch is higher than for the stable tree.  Indeed, you
would probably see a completely different response if this was a
problem using the ~x86 gcc to build the ~x86 xine-lib.

> > And putting the checks in portage doesn't seem to work very well
> > either.
>
> I fail to see how a test in the ebuild for the active
> GCC compiler version wouldn't work?

But that isn't putting a check "in portage", it is adding it to the ebuilds.

> > The system as it is now actually seems to work about right... the
> > vast majority of stable users upgrade to new versions of gcc as they
> > come out
>
> I'd think that most users hadn't even run into this problem (yet),

Agreed...

> because many source code maintainers strive to be able to compile with
> as old a version of GCC as possible..

or alternatively, because most users upgrade gcc to the current
version before running into such problems.

-Richard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Portage: missing pieces

[Richard Fish]

On 7/10/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
> It shouldn't even be _necessary_ to create bugs and receive advice
> from a living, breathing human being just to perform a system update.

It isn't necessary.  -user, the forums, IRC, all are monitored by
"living, breathing human beings".

-Richard
-- 
gentoo-dev@gentoo.org mailing list