# emerge -pvt geos These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild U ] sci-libs/geos-2.2.2-r1 [2.2.2] USE="python -doc -examples% -ruby% -static" 541 kB [ebuild N ] dev-lang/ruby-1.8.5_pre1 USE="tcltk threads -cjk -doc -examples -ipv6 -socks5" 4,298 kB [ebuild N ] dev-ruby/ruby-config-0.3.2 0 kB Total size of downloads: 4,839 kB # emerge --info Gentoo Base System version 1.12.1 Portage 2.1.1_pre2-r2 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17-gentoo-r1 i686) ================================================================= System uname: 2.6.17-gentoo-r1 i686 Mobile AMD Athlon(tm) XP 2600+ ccache version 2.4 [enabled] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -funroll-loops" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -funroll-loops" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="it_IT" LC_ALL="it_IT.UTF8" LINGUAS="it" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 7zip X aac aalib acpi aim alsa apache2 audiofile avi berkdb bitmap-fonts bzip2 caps cdparanoia cdr cli crypt cups dba dbase dbus dga dio dlloader dri dts dvb dvd dvdr dvdread emboss encode esd fbcon ffmpeg fftw firefox flac flatfile foomaticdb fortran ftp gcj gdbm geoip gif gnutls gpm gps gstreamer gtk gtk2 hal iconv icq ieee1394 imagemagick imap imlib isdnlog jabber jack javascript jpeg jpeg2k lcms lesstif libcaca libg++ libgda libwww mad matroska mbox md5sum mhash mikmod mime mmap mmx mng motif mp3 mpeg msn nas ncurses nis nls nptl nsplugin odbc offensive ogg opengl oscar oss pam pcmcia pcre pdf pdflib perl php pic png posix postgres ppds pppd python qt qt3 qt4 quicktime readline reflection samba sdl session sharedmem sndfile soap sockets sox spell spl sse ssl svg sysvipc szip tcltk tcpd tetex theora threads tiff timidity truetype truetype-fonts type1-fonts udev unicode usb v4l vcd vorbis win32codecs wmf wxwindows xinerama xml xml2 xmlrpc xorg xosd xpm xprint xsl xv xvid yahoo zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_synaptics kernel_linux linguas_it userland_GNU video_cards_via video_cards_vesa video_cards_fbdev video_cards_v4l" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS Reproducible: all time. Workaround: masking geos-2.2.2-r1. Anyone else with the same problem?
Well, ruby eclass depends on virtual/ruby unconditionally, so... no really ebuild's fault.
(In reply to comment #1) > Well, ruby eclass depends on virtual/ruby unconditionally, so... no really > ebuild's fault. Well, I think it IS ebuild's fault: simply deleting ruby.eclass may resolve this issue, since geos libs aren't write in ruby... Thanks for the quick reply.
(In reply to comment #2) > Well, I think it IS ebuild's fault: simply deleting ruby.eclass may resolve > this issue, since geos libs aren't write in ruby... Except that you can't compile the ruby bindings then, kinda sucks :=)
(In reply to comment #3) > Except that you can't compile the ruby bindings then, kinda sucks :=) Ok, but seems to me a nonsense to compile ruby only to have geos without ruby-bindings... And the only function used here from ruby.eclass is erubydoc. Thanks again.
(In reply to comment #4) > Ok, but seems to me a nonsense to compile ruby only to have geos without > ruby-bindings... And the only function used here from ruby.eclass is erubydoc. Doesn't matter... the real bug is that there's currently no way to inherit ruby.eclass and use its functions without pulling in the unconditional ruby dependency. I.e., the eclass is not useful for ebuilds that only compile ruby stuff when USE=ruby is set. Solution? Fex.: if [[ ${RUBY_OPTIONAL} != "yes" ]] ; then DEPEND="${DEPEND} virtual/ruby" else DEPEND="${DEPEND} ruby? ( virtual/ruby )" fi Then you can set RUBY_OPTIONAL="yes" in ebuilds and only depend on ruby when ruby use flag is set.
(In reply to comment #5) > Solution? Fex.: This solution is for ruby.eclass, isn't it? If it's so, it's a good point and that eclass must be fixed. Have I to open a new bug? Thanks again.
Created attachment 91134 [details] Proposed ebuild for geos-2.2.2-r2.ebuild Please commit this ebuild (or change the 2.2.2-r1 one) to fix this bug. Thanks.
Hey, can this issue be fixed or have we to wait next pope? It's been a month that a fix was proposed... Thanks again.
looks like the sci herd needs some new blood. Are you volunteering? :)
Hi Emiliano, Thank you very much for your fix. Since the last conclave wasn't too long ago I figured I won't wait for the next one and went ahead and fixed this in cvs ;-) Thanks, Markus
> looks like the sci herd needs some new blood. Are you volunteering? > :) Is it a serious proposal? Well, I'm very honored, but I don't think I have so much time and my knowledge of how portage works is limited to fixing some ebuild problems of projects that I follow. > Thank you very much for your fix. Since the last conclave wasn't too > long ago I figured I won't wait for the next one and went ahead and > fixed this in cvs ;-) Thank you and I'm very sorry of being rude on my last comment. I know you sci-developers are very busy, but the projects I follow are quicker in development; sometimes, at the time of inserting in portage of a version of, say, GRASS GIS, a new version is released. It's a bit sad because other distributions can insert packages in some hours before the release announcement. Thanks again, Emiliano
(In reply to comment #11) > Thank you and I'm very sorry of being rude on my last comment. I know > you sci-developers are very busy, but the projects I follow are > quicker in development; sometimes, at the time of inserting in portage > of a version of, say, GRASS GIS, a new version is released. It's a bit > sad because other distributions can insert packages in some hours > before the release announcement. Hi Emiliano, No worries, I didn't find your comments rude. We sci-devs try to do our best to fix things in a timely manner. But by now Gentoo has so many scientific packages some of which are fairly complex to build and maintain that it sometimes just takes a little to get things done. cheers, Markus
