Hi, emerge -u world tried to update mldonkey to 2.6.2 and fails with this error: >>> md5 files ;-) mldonkey-2.6.0.ebuild >>> md5 files ;-) mldonkey-2.5.16-r10.ebuild >>> md5 files ;-) mldonkey-2.5.16-r9.ebuild >>> md5 files ;-) mldonkey-2.5.27-r1.ebuild >>> md5 files ;-) mldonkey-2.6.2.ebuild >>> md5 files ;-) mldonkey-2.5.21-r2.ebuild >>> md5 files ;-) mldonkey-2.5.28-r4.ebuild >>> md5 files ;-) files/mldonkey.png >>> md5 files ;-) files/mldonkey.confd >>> md5 files ;-) files/mldonkey.initd >>> md5 files ;-) files/digest-mldonkey-2.6.0 >>> md5 files ;-) files/digest-mldonkey-2.6.2 >>> md5 files ;-) files/digest-mldonkey-2.5.16-r9 >>> md5 files ;-) files/digest-mldonkey-2.5.21-r2 >>> md5 files ;-) files/digest-mldonkey-2.5.27-r1 >>> md5 files ;-) files/digest-mldonkey-2.5.28-r4 >>> md5 files ;-) files/digest-mldonkey-2.5.16-r10 >>> md5 files ;-) files/2.5.28-config.patch >>> md5 files ;-) files/mldonkey-2.5.21-configure.patch >>> md5 files ;-) files/mldonkey-2.6.0-gtk2-gentoo.patch >>> md5 files ;-) files/mldonkey-gui.desktop >>> md5 files ;-) files/mldonkey >>> md5 files ;-) files/mldonkey-2.5.16-configure.patch >>> md5 src_uri ;-) mldonkey-2.6.2.tar.bz2 * If the compile with gui fails, and you have updated ocaml * recently, you may have forgotten that you need to run * /usr/portage/dev-lang/ocaml/files/ocaml-rebuild.sh * to learn which ebuilds you need to recompile * each time you update ocaml to a different version * see the ocaml ebuild for details * Only one GUI must be chosen! (gtk || gtk2 || oldgtk) !!! ERROR: net-p2p/mldonkey-2.6.2 failed. !!! Function pkg_setup, Line 46, Exitcode 0 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. I run ocaml-rebuild.sh: sh /usr/portage/dev-lang/ocaml/files/ocaml-rebuild.sh Cleaning "net-p2p/mldonkey-2.6.0" "dev-ml/lablgl-1.00" "dev-ml/lablgtk-2.4.0" "dev-ml/lablgtk-1.2.7" Building ">=net-p2p/mldonkey-2.6.0" ">=dev-ml/lablgl-1.00" ">=dev-ml/lablgtk-2.4.0" ">=dev-ml/lablgtk-1.2.7" These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] net-p2p/mldonkey-2.6.2 [2.6.0] [ebuild R ] dev-ml/lablgl-1.00 [ebuild R ] dev-ml/lablgtk-2.4.0 so nothing changed ;) Reproducible: Always Steps to Reproduce: 1.emerge sync 2.emerge -u world 3. Actual Results: the emerge aborts- Expected Results: mldoney should be updated ;) emerge info Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r9 i686) ================================================================= System uname: 2.6.12-gentoo-r9 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.12.0_pre6 ccache version 2.4 [enabled] dev-lang/python: 2.2.3-r5, 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -mmmx -m3dnow -msse -mfpmath=sse -ftracer -frename-registers -fweb -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/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -mmmx -m3dnow -msse -mfpmath=sse -ftracer -frename-registers -fweb -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy ccache distlocks notitles sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="de_DE@euro" LINGUAS="de" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 16bit 3dnow 3dnowext 3ds 7zip S3TC X X509 a52 aac aalib acpi alsa audiofile avi bash-completion berkdb bitmap-fonts bl bluetooth bzip2 bzlib cairo caps cdparanoia cdr cpudetection crypt css ctype curl dga dio divx4linux dnd dpms dvd dvdr dvdread editor edl eds emacs-w3 emboss encode exif expat fame fb fbcon ffmpeg fftw flac fortran freetype ftp gcc-libffi gd gdbm gif gimp glitz gnokii graphviz gs gstreamer gtk gtk2 hal icq imagemagick imlib irmc jack jack-tmpfs java javascript jce joystick jp2 jpeg jpeg2k kde kdeenablefinal ladcca lesstif libg++ libwww lm_sensors lzw lzw-tiff mad maildir maps matroska mikmod mjpeg mmap mmx mmxext mng monkey motif mp3 mpeg mpi mplayer mule music mysql ncurses nls no-htdocs no-old-linux noamazon nocd nodrm noflagstrip nosendmail nowin nptl nvidia objc offensive ogg oggvorbis openal opengl oscar pam pam_console pam_timestamp pdflib perl physfs pic png posix povray python qemu-fast qt quicktime rar readline real reiserfs rogue samba scanner sdl sensord server sharedmem shorten slang sms sndfile snmp sockets sounds speex spell sqlite sse ssl stencil-buffer subtitles svg szip tcltk tcpd tga theora threads tiff timidity tools transcode truetype truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 vanilla vcd videos vidix visualization vorbis win32codecs wmf wsconvert xanim xemacs xine xinerama xml2 xmlrpc xmms xosd xpm xrandr xscreensaver xv xvid xvmc yv12 zlib zvbi linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, MAKEOPTS
> Only one GUI must be chosen! (gtk || gtk2 || oldgtk) You can use only ONE of the above flags, as the error message says. Not a bug.
Hi, it IS a bug, because it forces me to change valid useflags. from the description: gtk - Adds support for x11-libs/gtk+ (The GIMP Toolkit) gtk2 - Use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both. so, from what I read, it should choose gtk2 if supported, and gtk2 is supported, and do not whine about the other flags, right? If gtk2/gtk are exclusive, someone should say so in use.desc and not abort an emerge.
If you don't like INVALID, closing CANTFIX then. You simply cannot emerge this w/ multiple GUIs and that's exactly what the ebuild message says. Adjust your USE flags for this ebuild in /etc/portage/package.keywords.
Hi, do not want to emerge it with multiple guis *sigh* Again: the useflags say: if gtk2 is available, choose it. I understand the useflags this way: if gtk2 is available, choose gtk2. If gtk2 is not available, choose gtk1. But the ebuild fails, because of multiple guis. This is a bug. And I do not care, if this is an ebuild bug, or an use-bug. Bug is bug ;)
Created attachment 66513 [details, diff] proposed patch The thing is: Volker is right. The gtk use flag is defined as "use any kind of gtk-support", while gtk2 means "use gtk2 over gtk". Yes, this sux, but that's the way the rest of Gentoo uses them, so mldonkey should, too. This patch changes the meaning of the use flags in the ebuild as follows: A gui is build if gtk or guionly is set. (A user setting guionly obviously wants a gui, no need to abort). Which one, is determined by the gtk2 and oldgtk use flags: gtk2: Build gtk2 gui oldgtk: Build old gtk1 gui !gtk2 && !oldgtk: Build new gtk1 gui This patch is _NOT_ testet, cause it is 2:30am, and I'm going to bed now...
Created attachment 66532 [details, diff] proposed patch Some more cleanups, to make the logic clearer. I tested this ebuild with USE="gtk gtk2 -oldgtk", and got a working gtk2-GUI, as expected.
Reopening, i'll test that patch and add it to portage.
Hmm..... emerge-auto-selection isn't bad idea, imho. still - proposed autoselection isn't right.... at least for me. why? oldgtk is local, mldonkey only specific USE flag. If used - these should be first choice. imho gtk2 should be a second choice, before gtk gtk should be used if there was no oldgtk or gtk2 last problem: installing mldonkey without any of above USE flags, but with guionly -> we should add some default choice for this situation this is how I see this should be resolved. I'm making an ebuild now. Should be ready nto long from now. Cheers, Przemek
Created attachment 66574 [details] mldonkey-2.6.2.ebuild ok - ebuild handle the procedure of choosing a gui, I described in previous post. 1. oldgtk - highest choice 2. gtk2 3. gtk || guionly For guionly version, without specified gui type, I put gtk one to be installed. This was my choice, and therefore I'm not sure is it the best one. What you think of this? PS. My english isn't perfect.... It's highly possible I made a terrible mistakes in ebuild's comments. Plz - check it ;) Regards, Przemek
one more.... isn't gd only for web stats? if so - we should disable this with guionly USE flag, but I'm not sure of this. Maybe someone knows how is it?? Regards, Przemek
elif [[ $chosengui != 0 ]]; then ewarn "QAUTION! Multiple use flags for building mldonkey's gui" ewarn "was detected. Mldonkey may be build with only one gui type." No, this is plain wrong. USE="gtk gtk2" is a perfectly valid combination and shouldn't trigger a warning. Keep in mind that USE="gtk" does _NOT_ mean "I want gtk1".
Created attachment 66578 [details, diff] proposed patch >oldgtk is local, mldonkey only specific USE flag. If used - these should be first choice. You have a point there. How about this?
Created attachment 66579 [details, diff] proposed patch Forget about that one, made a silly mistake.
Created attachment 66580 [details] mldonkey-2.6.2.ebuild (In reply to comment #11) > No, this is plain wrong. USE="gtk gtk2" is a perfectly valid combination and > shouldn't trigger a warning. Keep in mind that USE="gtk" does _NOT_ mean "I want > gtk1". hmmmm... absolutelly true! :| so why not this way? I just changed elif [[ $chosengui == 2 ]]; then to elif [[ $chosengui == 2 || $chosengui == 3 ]]; then This will do the trick... I think. Regards, Przemek
No, this still uses USE=gtk as "I want gtk1", which is not what it means in the rest of Gentoo.
(In reply to comment #15) > No, this still uses USE=gtk as "I want gtk1", which is not what it means in the > rest of Gentoo. Ok - you're saying about gtk + gtk2 flags: - if both than gtk2 - if only first, than gtk Am I right? If so - than ebuild I submitted, will first look is gtk2 is selected. If not - will check for gtk and situation will be like !gtk2 && gtk. Something like this is gtk1, isn't it? Regards, Przemek
Created attachment 66584 [details] mldonkey-2.6.2.ebuild ebuild with using gtk2 gui only when gtk && gtk2 USE flags are set Cheers, Przemek
(In reply to comment #14) > Created an attachment (id=66580) [edit] > mldonkey-2.6.2.ebuild Could you explain why are you doing all the complicated lengthy "magic" in pkg_setup() only to compile this later on based on oldgtk || gtk2 || gtk || guionly flags, while ${chosengui} remains totally unused for the actual compile? What is the purpose of that pkg_setup() thing then? Could you please keep this ebuild as simple as possible w/o bringing in a "logic" that most users will fail to understand anyway?
if use oldgtk; then myconf="--enable-gui=oldgui" [...] elif use guionly; then myconf="--enable-gui=newgui1 --disable-multinet --disable-donkey" [...] fi So, if I set USE="oldgtk guionly", I still get the server? Besides that... IMHO oldgtk should work the same way as gtk2, everything else is confusing.
(In reply to comment #19) > So, if I set USE="oldgtk guionly", I still get the server? hihihihi - too fast :) you are right :) > Besides that... IMHO oldgtk should work the same way as gtk2, everything else is > confusing. ?? why? oldgtk is oldgtk and gtk2 is gtk2.... imho (In reply to comment #18) > Could you explain why are you doing all the complicated lengthy "magic" in > pkg_setup() only to compile this later on based on oldgtk || gtk2 || gtk || > guionly flags, while ${chosengui} remains totally unused for the actual compile? > What is the purpose of that pkg_setup() thing then? to inform user what will be installed... but yes - it can be done much simpler... I'm tired... will try to do that. > Could you please keep this ebuild as simple as possible w/o bringing in a > "logic" that most users will fail to understand anyway? as mentioned - I will try ;) Regards, Przemek
(In reply to comment #20) > > Besides that... IMHO oldgtk should work the same way as gtk2, everything else is > > confusing. > ?? why? oldgtk is oldgtk and gtk2 is gtk2.... imho Yes, but (in the context of this ebuild), they both select a specific gtk gui. Having one of them depend on gtk, while the other does not, is confusing.
(In reply to comment #20) > > What is the purpose of that pkg_setup() thing then? > to inform user what will be installed... but yes - it can be done much > simpler... I'm tired... will try to do that. Hmm, the user has been informed perfectly well so far that he can select only one GUI and he could be sure that if he sets "gtk -gtk2" in package.use, then he'll get gtk1 GUI, if he sets "-gtk gtk2" then he'll get gtk2 GUI and if he sets "oldgui -gtk -gtk2" then he'll get old GUI (whatever that means). Now user's safest bet would probably be to keep trying until he gets what he wants. > > Could you please keep this ebuild as simple as possible w/o bringing in a > > "logic" that most users will fail to understand anyway? > as mentioned - I will try ;) OK, so what about putting gui-gtk1 and gui-gtk2 into IUSE and maintaining the previous logic w/ ebuild bailing out when user selects more than one; if you really can't bear that you cannot have both gtk and gtk2 in use flags b/c it contradicts some general description of the global use flags? More local use flags is definitely evil, bug IMHO still less evil than introducing some difficult to understand logic which makes ebuild twice that big and much less readable. (In reply to comment #21) > Yes, but (in the context of this ebuild), they both select a specific gtk gui. > Having one of them depend on gtk, while the other does not, is confusing. See above. Honestly, I still think that this whole patch is not needed at all.
Created attachment 66586 [details, diff] proposed patch I really should triple check before posting patches... Didn't notice, that the ebuild in portage had changed.
(In reply to comment #22) > OK, so what about putting gui-gtk1 and gui-gtk2 into IUSE and maintaining the > previous logic w/ ebuild bailing out when user selects more than one; if you > really can't bear that you cannot have both gtk and gtk2 in use flags b/c it > contradicts some general description of the global use flags? More local use > flags is definitely evil, bug IMHO still less evil than introducing some > difficult to understand logic which makes ebuild twice that big and much less > readable. This isn't an 'evil idea'. Similar problem was with OOorg-ximian kde icons : they were moved to local use flag, since kde USE flag wasn't ideal solution to handle this. I vote for gui-{oldgtk,gtk1,gtk2} local USE flags. Cheers, Przemek
(In reply to comment #22) > OK, so what about putting gui-gtk1 and gui-gtk2 into IUSE and maintaining the > previous logic w/ ebuild bailing out when user selects more than one; if you > really can't bear that you cannot have both gtk and gtk2 in use flags b/c it > contradicts some general description of the global use flags? More local use > flags is definitely evil, bug IMHO still less evil than introducing some > difficult to understand logic which makes ebuild twice that big and much less > readable. The gtk/gtk2 logic may be flawed but it has been etablished as a gentoo-wide standard. "gtk" means to use ANY gtk support, if I set it, I get gtk-apps, no matter if gtk1 or gtk2. If I set the "gtk2" useflag, I get gtk2-apps whenever it's possible. So "+gtk +gtk2" is a perfectly valid combination which says I want gtk2-apps whenever possible, if not, at least give me gtk1-apps. This is honoured by many other packages and users set their use flags according to this, because this is the meaning of these use flags. Now if every package containing a gtk1/gtk2-choice would create their own local use flags...what a mess :) So please don't introduce more use flags for mechanisms that are well-known in the tree :) In fact this also makes every system with proper set use flags stumble upon the mldonkey ebuild when emerged, probably confusing the user even more because he has indeed set his flags according to his liking and to specifications. (In reply to comment #24) > This isn't an 'evil idea'. Similar problem was with OOorg-ximian kde icons : > they were moved to local use flag, since kde USE flag wasn't ideal solution to > handle this. The gtk/gtk-use flags were created to decide upon which gtk-support should be compiled and have a well-known behaviour. This is exactly what they are designed for (except a third oldgtk-gui coming along but sensible solutions have been proposed)
(In reply to comment #22) > More local use > flags is definitely evil, bug IMHO still less evil than introducing some > difficult to understand logic which makes ebuild twice that big and much less > readable. If you look at my ebuild, you'll see that - it's only slightly more difficult to understand than any other ebuild with the gtk/gtk2 use flags, simply because it uses the same logic. The only addition is the oldgtk use flag, but that's handled it _exactly_ _the_ _same_ _way_ as the gtk2 use flag. - it adds one (1) line of code in total.
(In reply to comment #25) > please don't introduce more use flags for mechanisms that are well-known in the > tree :) OK, if the following is a well-known mechanism then I vote for more local use flags: + if !(use gtk || use guionly) && use oldgtk; then + ewarn "You have oldgtk in your USE flags, but not gtk." + ewarn "This will _NOT_ build _ANY_ gui. To build the old gtk gui," + ewarn "Enable the gtk use flag." This has no logic, sorry. The user selected oldgtk so it's what he should get. The use flag description says "enable old gtk user interface" and user gets no GUI whatsoever? Where's the improvement then? > In fact this also makes every system with proper set use flags stumble upon the > mldonkey ebuild when emerged, probably confusing the user even more because he > has indeed set his flags according to his liking and to specifications. No, to the contrary - the above patch confuses users like hell. Should the ebuild changes go this way, I'd really recommend closing this bug WONTFIX/CANTFIX again.
Jakob: /usr/portage/profiles/use.desc clearly states that the "gtk" USE flag requests that a package builds a GTK GUI, if available, while the "gtk2" USE flag requests that the package builds a GTK 2 GUI if possible, or GTK 1 if not (assuming gtk is also set). Therefore, the current mldonkey ebuild needs changing so that the combination "gtk gtk2" is treated the same way as "-gtk gtk2" is treated by the current ebuild. The following patch implements exactly this behaviour, and should be the minimal change needed to make this ebuild behave like other GTK applications. The error message may need updating. --- mldonkey-2.6.2.ebuild 2005-08-21 22:05:59.000000000 +0100 +++ mldonkey-2.6.2.ebuild.new 2005-08-22 23:48:00.000000000 +0100 @@ -41,7 +41,7 @@ einfo "see the ocaml ebuild for details" echo "" - if (use gtk && use gtk2) || (use gtk && use oldgtk) || (use gtk2 && use oldgtk); then + if (use gtk && use oldgtk) || (use gtk2 && use oldgtk); then eerror "Only one GUI must be chosen! (gtk || gtk2 || oldgtk)" die "Choose only one GUI" fi It relies on the fact that GUI selection is done by an if...elif...elif...fi chain.
(In reply to comment #28) > The following patch implements exactly this behaviour, and should be the > minimal change needed to make this ebuild behave like other GTK applications. No, it's not. - You need to change the dependencies, too. Otherwise you end up with unneeded deps on gtk1 in the USE="gtk gtk2" case. - If gtk is unset, other GTK applications don't built optional GTK support, even if gtk2 is set.
(In reply to comment #29) > (In reply to comment #28) > > The following patch implements exactly this behaviour, and should be the > > minimal change needed to make this ebuild behave like other GTK applications. > > No, it's not. > - You need to change the dependencies, too. Otherwise you end up with unneeded > deps on gtk1 in the USE="gtk gtk2" case. > - If gtk is unset, other GTK applications don't built optional GTK support, even > if gtk2 is set. I think the general principle still applies. If you set oldgtk, you implicitly expect the old GTK 1 GUI. If you set gtk, but not gtk2, you're expecting a GTK 1 version of the new GUI, and if you set gtk and gtk2, you're expecting a GTK 2 version of the new GUI. I'll work on my patch a little, and try and clean up the dependency issue, together with preventing gtk2 from building if gtk is unset.
Created attachment 66597 [details, diff] mldonkey-2.6.2.ebuild.patch OK, this debate is already overly lengthy, considering the trivial issue. So, the above patch removes the check for muptiple gui flags, implements oldgui - gtk2 - gtk1 in this order of preference (local use flag should not clash w/ global ones) and fixes the dependencies. Period. (In reply to comment #29) > - If gtk is unset, other GTK applications don't built optional GTK support, even > if gtk2 is set. So what. I could really care less... Lets really stop making this a rocket science and stop complicating the ebuild.
(In reply to comment #27) > OK, if the following is a well-known mechanism then I vote for more local use flags: > > + if !(use gtk || use guionly) && use oldgtk; then > + ewarn "You have oldgtk in your USE flags, but not gtk." > + ewarn "This will _NOT_ build _ANY_ gui. To build the old gtk gui," > + ewarn "Enable the gtk use flag." > > This has no logic, sorry. The user selected oldgtk so it's what he should get. > The use flag description says "enable old gtk user interface" and user gets no > GUI whatsoever? Where's the improvement then? This happens if the user explicitly set -gtk in his useflags, stating explicitly that he does not want _any_ gtk-app. If he now sets oldgtk to request the old gtk gui, this is a contradiction which can and should be noted by the ebuild.
Created attachment 66598 [details, diff] Patch to set order, and warn if oldgtk is enabled with -gtk This patch does the following: 1) *Always* builds the old GUI if oldgtk is set. If gtk is not also set, a warning is issued with ewarn. 2) Otherwise, builds (with correct dependencies) the GTK 2 new GUI if both gtk and gtk2 are set, or the GTK 1 new GUI if only gtk is set. If neither are set, no GUI is built.
(In reply to comment #33) > Created an attachment (id=66598) [edit] > Patch to set order, and warn if oldgtk is enabled with -gtk > Just to note; I wrote and attached this patch before seeing Jakob's patch. I'm not bothered about it, I'm just after some resolution to this bug (so that the in-tree ebuild succeeds with the standard "gtk gtk2" USE flags set).
(In reply to comment #31) > OK, this debate is already overly lengthy, considering the trivial issue. It doesn't seem that trivial to me, otherwise there wouldn't be so many broken ebuilds (including yours) flying around... > So what. I could really care less... Lets really stop making this a rocket > science and stop complicating the ebuild. You prefer a quick solution over a correct one? Please tell me you're kidding?
Removing myself from CC, I've just had enough of this bugspam.
Maybe just drop oldgui feature? Does anybody really use it? It would simplify the ebuild and make things easier.
If oldgtk gui is unsupported anymore (is it?), than dropping it maybe not a bad idea. The hole problem, will magicly dissapear then :) But if oldgtk means 'old style', that still has a meintainer -> then dropping this wouldn't be a best idea. My 2 cents. Regards, Przemek
*** Bug 104633 has been marked as a duplicate of this bug. ***
Hi, any good reason why mldonkey 2.6.4 fails with the exact same problem?
Created attachment 67959 [details] New ebuild Some changes: * Drop oldgui USE flag because it's deprecated (talked with mldonkey dev) * Use gtk2 over gtk when both USE flags are enabled Waiting for comments. This way of handling gtk flags is proper with gentoo policy.
Created attachment 67961 [details] Fixed RDEPEND Fixed RDEPEND variable
new version in cvs. i've cleaned-up a bit. after consulting with Karol Wojtaszek, we've decided to drop oldgtk flag. The old version of gtk1 gui isn't maintained anymore and'll propably be removed in near future. gtk and gtk2 are treated exactly the way, as they're defined in profiles/use.desc. thanks everyone for taking part in this discussion and i hope all of you'll find new ebuild at least "acceptable"
