Currently, stable fpc is version 2.0.0-r1, while stable lazarus is 2.0.0_rc2. If you emerged explicitelly fpc and lazarus, a downgrade/upgrade loop occurs, and you downgrade/upgrade everytime you do "emerge world". This is caused by a very strict dependency from lazarus (depends on =fpc-2.0.0_rc2), a version prior to the stable fpc version. There's an easy workaround to this, unmerging fpc and reemergin lazarus, but that shoudn't be used. fpc-2.0.0-r1 should be better than 2.0.0_rc2, and should be used instead. The solution is to change the ebuild to depend on >=fpc-2.0.0_rc2 instead of =fpc-2.0.0_rc2. A new version of lazarus is on the way, and I noticed that the same problem will arise, as i noticed there's a requirement for =fpc-2.0.0-r1.... Reproducible: Always Steps to Reproduce: 1.emerge fpc 2.emerge lazarus 3.emerge world -uDvp Actual Results: fpc is downgraded while emerging lazarus, and upgraded again on emerge world. Subsequent "emerge world" with continue the loop. Expected Results: Lazarus should use the more recent stable fpc, and not forcing to downgrade it. Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.6.12-gentoo-r7 i686) ================================================================= System uname: 2.6.12-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.2.3-r5, 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -mcpu=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.rnl.ist.utl.pt/pub/gentoo http://darkstar.ist.utl.pt/gentoo http://ftp.gentoo-pt.org/pub/gentoo ftp://gentoo.chem.wisc.edu/gentoo/ ftp://ftp.rxd.hu ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://mirror.datapipe.net/gentoo rsync://linux.rz.ruhr-uni-bochum.de/gentoo/ rsync://planetmirror.com/gentoo/" LANG="pt_PT@euro" LINGUAS="pt" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X Xaw3d aac aalib acpi alsa apm avi berkdb bitmap-fonts cdparanoia cdr crypt cups curl directfb divx4linux dvd dvdr eds emboss encode fam fbcon flac font-server foomaticdb fortran gcj gdbm gif glibc-compat20 gpm gstreamer gtk gtk2 imagemagick imlib jack java jpeg kde kdeenablefinal kdexdeltas libcaca libg++ libwww lirc live mad matroska mikmod mmx mmxext motif mp3 mpeg nas ncurses network nls nptl nvidia offensive ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline samba sdl slang spell sqlite sse sse2 ssl stroke svg svga swsusp2 tcltk tcpd tetex threads tiff tls truetype truetype-fonts type1-fonts usb v4l v4l2 videos vorbis win32codecs xine xml xml2 xmms xpm xv xvid zlib linguas_pt userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS
Renato, please don't reassign bugs back to bug wranglers.
Lazarus 0.9.10 now in portage which uses fpc* 2.0.0.
NO! THE BUG IS NOT SOLVED! It is only delayed.. As i said before, the new ebuild of lazarus still depends on "=dev-lang/fpc-2.0.0-r1" so if fpc-2.0.0-r2 comes out the bug will return. And I bet if -r2 does come out, the bug will persist for a long time before someone takes some action.
YES IT IS. Each version of lazarus depends on specific fpc versions to work well so there's no other way to do is. As of this writing this is solved and since i'm the one maintaining fpc AND lazarus there's no chance what you say will happen since i'll change the deps when/if appropiate.
Ok if you say so. As long as you don't change the lazarus deps only a week (or more) after, that's ok with me.