| Summary: | Gtk-engines imlib dependency | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ronald Hummelink <ronald> |
| Component: | [OLD] Library | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | 3.14159, amax, anakin.skyw, betelgeuse, carpaski, chutz+bugs.gentoo.org, dju, dwc, fabian, flash3001, gentoo, gent_bz, greg_g, hanno, ian, iyosifov, jforman, ladanyi, langthang, lucass, marienz, mark, maxima, michal, qa, releng, ringo0, robmoss, sascha-gentoo-bugzilla, seemant, tom.gl, web, wjmcqueen, xero |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
nocache.patch
A posible solution 2.0.51-r15--recache_restrict_flag.patch |
||
|
Description
Ronald Hummelink
2003-07-14 03:13:46 UTC
*** Bug 24634 has been marked as a duplicate of this bug. *** i've slightly modified the ebuild so it looks like
[ -n "${HAS_GTK1}" ] && newdepend ">=media-libs/imlib-1.8"
and it works fine here, i've tested it with combinations of gtk+-1.2/imlib
and it pulls it in when it isnt installed, or doesnt if it is allready. please
test.
*** Bug 27400 has been marked as a duplicate of this bug. *** i assume this is fixed now Obz/lqx ? closing, reopen if needed. This will not catch a GRP state. newrdepend is probably what should be used instead of newdepend. (there is only a buildtime dependency, not a run-time one) It's a shared lib, isn't it ? So we'd need it both build & runtime. Now I've encountered the opposite issue: gtk-engines *always* wants to install imlib, which in turn installs gtk+-1.x. On my (pure) gtk2 system, this is undesirable. Although x11-libs/gtk+-1.2* is definitely not installed on my system and USE="-gtk" is set, the gtk-engines ebuild still seems to want imlib installed. Is there an easy workaround (except for injecting imlib)? FYI: user@host $ emerge -dpv gtk-engines These are the packages that I would merge, in order: Calculating dependencies Parent: None Depstring: x11-themes/gtk-engines Candidates: ['x11-themes/gtk-engines'] ebuild: x11-themes/gtk-engines-2.2.0 binpkg: None \ Parent: ebuild / x11-themes/gtk-engines-2.2.0 merge Depstring: >=media-libs/imlib-1.8 gtk2? ( >=x11-libs/gtk+-2 ) : ( =x11-libs/gtk+-1.2* ) sys-devel/gnuconfig !bootstrap? ( sys-devel/libtool ) >=media-libs/imlib-1.8 Candidates: ['>=media-libs/imlib-1.8'] ebuild: media-libs/imlib-1.9.14-r1 binpkg: None | Parent: ebuild / media-libs/imlib-1.9.14-r1 merge Depstring: =x11-libs/gtk+-1.2* >=media-libs/tiff-3.5.5 >=media-libs/giflib-4.1.0 >=media-libs/libpng-1.2.1 >=media-libs/jpeg-6b !bootstrap? ( sys-devel/libtool ) =x11-libs/gtk+-1.2* >=media-libs/tiff-3.5.5 >=media-libs/giflib-4.1.0 >=media-libs/libpng-1.2.1 >=media-libs/jpeg-6b Candidates: ['=x11-libs/gtk+-1.2*', '>=media-libs/giflib-4.1.0'] ebuild: x11-libs/gtk+-1.2.10-r10 binpkg: None / Parent: ebuild / x11-libs/gtk+-1.2.10-r10 merge Depstring: virtual/x11 =dev-libs/glib-1.2* nls? ( sys-devel/gettext dev-util/intltool ) !bootstrap? ( sys-devel/patch ) !bootstrap? ( sys-devel/libtool ) virtual/x11 =dev-libs/glib-1.2* nls? ( sys-devel/gettext dev-util/intltool ) Candidates: [] Exiting... ebuild / x11-libs/gtk+-1.2.10-r10 merge ebuild: media-libs/giflib-4.1.0-r3 binpkg: None - Parent: ebuild / media-libs/giflib-4.1.0-r3 merge Depstring: X? ( virtual/x11 ) sys-devel/gnuconfig !bootstrap? ( sys-devel/libtool ) X? ( virtual/x11 ) Candidates: [] Exiting... ebuild / media-libs/giflib-4.1.0-r3 merge Exiting... ebuild / media-libs/imlib-1.9.14-r1 merge Exiting... ebuild / x11-themes/gtk-engines-2.2.0 merge Exiting... None ...done! [ebuild N ] x11-libs/gtk+-1.2.10-r10 -debug +nls 2,880 kB [ebuild N ] media-libs/giflib-4.1.0-r3 +X +gif 294 kB [ebuild N ] media-libs/imlib-1.9.14-r1 731 kB [ebuild R ] x11-themes/gtk-engines-2.2.0 0 kB Total size of downloads: 3,906 kB user@host $ emerge --info Portage 2.0.50 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.22-gentoo-r5) ================================================================= System uname: 2.4.22-gentoo-r5 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon -O2 -pipe -fomit-frame-pointer -ffast-math -funroll-loops -fforce-addr" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon -O2 -pipe -fomit-frame-pointer -ffast-math -funroll-loops -fforce-addr" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache digest sandbox userpriv usersandbox" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://gentoo.linux.no/ http://www.ibiblio.org/pub/Linux/distributions/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X acl acpi alsa avi berkdb bonobo cdr crypt cups dvd encode esd gif gnome gstreamer gtk2 imlib jikes jpeg libwww mad maildir mmx mpeg mpi ncurses nls oav odbc oggvorbis opengl pam pda pdflib png quicktime readline samba sdl spell ssl tcpd truetype x86 xml2 xv zlib" Portage caches the newdepend or absence thereof.
# USE="gtk2" emerge -p --tree gtk-engines
[ebuild N ] x11-themes/gtk-engines-2.2.0
[ebuild N ] media-libs/imlib-1.9.14-r1
[ebuild N ] x11-libs/gtk+-1.2.10-r11
[ebuild N ] x11-libs/gtk+-2.2.4-r1
# grep imlib /var/cache/edb/dep/x11-themes/gtk-engines-2.2.0
>=media-libs/imlib-1.8 gtk2? ( >=x11-libs/gtk+-2 ) : ( =x11-libs/gtk+-1.2* ) sys-devel/gnuconfig !bootstrap? ( sys-devel/libtool )
>=media-libs/imlib-1.8
# touch /usr/portage/x11-themes/gtk-engines/gtk-engines-2.2.0.ebuild
# emerge -p --tree gtk-engines
[ebuild N ] x11-themes/gtk-engines-2.2.0
[ebuild N ] x11-libs/gtk+-2.2.4-r1
# grep imlib /var/cache/edb/dep/x11-themes/gtk-engines-2.2.0
# USE="-gtk2" emerge -p --tree gtk-engines
[ebuild N ] x11-themes/gtk-engines-2.2.0
[ebuild N ] x11-libs/gtk+-1.2.10-r11
[ebuild N ] x11-libs/gtk+-2.2.4-r1
Since imlib requires gtk+-1, I propose removing the HAS_GTK1 test from the gtk-engines ebuild and modifying gtk-engines2.eclass to depend on >=media-libs/imlib-1.8 instead of =x11-libs/gtk+-1.2*.
This is probably the most horrible ebuild I've ever seen. I'm certain that conditional depends are illegal. Furthermore, the fact that this particular rubbish implementation doesn't work is blocking everyone who wants a pure gtk+-2 system from having one. Please fix this. Soon. Before I do it for you. For such a horrible bug, a year is far too long to wait for a fix. That conditional dep is not valid. Don't care how you kill it, but get it out of the tree. While you're at it, feel free to kill off the unneeded sed usage (minor compared to that has_gtk1 hack). This is only a bug because of an unneeded halfworking cache implementation, there is theory nothing wrong with this if it weren't for portage hacks blocking it. So don't talk rubbish on whats rubbish. & it's no ebuild robmoss, it's an eclass. & the engines stuff is probably the biggest mess in the world to get right. And if you want to fix, propose something. Don't make prolarizing threat-like comments without obviously any insight in the difficulty of the matter. Plus that it does work on a lot of systems for a fact. You come in with an attitude instead of trying te genuinely help out, obviously nobody was ever bothered enough with this 'major bug' to fix it. Foser, it's a bloody conditional dep. There's no two ways about it. It's invalid. It should not be in the tree. Sure, I'll fix it if you like. There's a valid fix in comment #9. If you don't like that, I'll split the ebuild (or whatever you want to call it) for you, with one depending on gtk-1* and one depending on gtk-2* - as it really should be. ebuild, eclass, whatever, I don't care - either gtk+-1* is going to need a near-total rewrite if you want it to work reliably when gcc-3.5 hits, or we need to be able to deprecate it reliably. I'll extend a partial apology for my outburst - I'd spent nearly two hours going mad over that by that point, so I reckon I was actually remarkably restrained - but I honestly believe that, despite what you say, my point remains. A conditional dep is a conditional dep is a conditional dep. And conditional deps are illegal. propose something, be aware that this extends to all gtk-engines* packages. And i dunno what this has todo with future gcc versions, aren't you taking it all a bit too far ? Err... Foser, we're not doing a repeat of bug #55708 here. You want this support, fine come up with a glep that is *fully* backwards compatible, and split a patch. If you're not willing to attempt to fix this issue (which isn't an issue imo), then you lose the right to bitch about it. This is a long standing policy. Fix it. As said, I'm fine with a fix, but it may prove harder than some here may think. This didn't bother most people for over a year now, makes the sudden attention it now gets more surprising. Sure device a fix & show it, we have more on our plate than a few engines to just all jump on it on command. And as far as I'm concerned, just dump the static cache and it won't be a problem, is that backwards compatible enough ? Created attachment 38335 [details, diff]
nocache.patch
Foser... quite frankly you don't know what you're talking about. Apply this
patch against portage-2.0.51_pre20, and take it for a spin.
It disables the cache.
I suggest you try running a emerge -ep world, or emerge-ep gnome and go for a
walk.
The cache is here to stay alright? Follow the rules, or take it up with devrel
(as I have).
As for problems with splitting the ebuild up, quite frankly that's -your-
problem. Every other maintainer/herd follows these rules, yet time and again
gnome ignores it and stupid lil flame fests like this start up.
As for this not being a problem for a year, that's by sheer luck. You do realize that -all- users have had an imlib dependency for gtk-engines-2.2.0, right? Regardless of their use flag specification, or installed packages? The environment of eagle results in imlib *always* being dep'd for rsync users, regardless of any conditional dep tricks you try... So the hack amounts to a perm. dep for all rsync users, w/ cvs users being the only ones who might end up with imlib left out of their deps.... Yeah, but this won't be a problem for portage anymore, right ? And there are other ways to speed things up if thats your concern (i guess thats what you want to prove with your patch). I may not be as much into portage as you, but i do know what's going on. Anway, you are the one flamefesting here once again, you come with endless pointless criticism, while I have already made clear that we will accept reasonable working patches. But no, according to your 3 last comments I have to write patches for your packages broken behaviour and you also tell me to fix ours ? That sounds pretty screwed up to me. Portage acts upon ebuilds, not the other way around. A dodgy benchmark I did showed sourcing ebuilds as opposed to using the cache is roughly 400 times slower. Real life (ie ferringb's patch) shows it's more like 100 times slower. There's absolutely no way to remove most of that performance hit. The only way to even get near to the cached times are by parsing the ebuilds manually, which would require possibly further restrictions on ebuilds than what there are now.
At present, there is only one class of ebuilds that use dynamic behaviour in the global scope that is acceptable - those that are dynamically slotted based on the version of another package. There is no alternative way to do it and the only breakage it causes is emerge sometimes showing an N instead of a U.
#####gtk-engines2.eclass#####
if has_version "=x11-libs/gtk+-1.2*"; then
HAS_GTK1=1
GTK1_ENGINES_DIR=/usr/lib/gtk/themes/engines
fi
if has_version ">=x11-libs/gtk+-2" || use gtk2; then
HAS_GTK2=1
GTK2_FULL_VER=$(pkg-config gtk+-2.0 --modversion 2>/dev/null)
GTK2_MAJOR_VER=${GTK2_FULL_VER%.*}.0
GTK2_ENGINES_DIR=/usr/lib/gtk-2.0/${GTK2_MAJOR_VER}/engines
fi
#############################
You could leave this as is and still fix this bug, although it really shouldn't be in the global scope. It should be in a separate function of the eclass that is called by the ebuilds when that information is required.
#####gtk-engines2.eclass#####
# --- define some deps for binary packages
if [ -n "${HAS_GTK1}" -a ! -n "${HAS_GTK2}" ]; then
DEPEND="${DEPEND} =x11-libs/gtk+-1.2*"
elif [ -n "${HAS_GTK1}" -a -n "${HAS_GTK2}" ]; then
DEPEND="${DEPEND} =x11-libs/gtk+-1.2* =x11-libs/gtk+-2*"
elif [ ! -n "${HAS_GTK1}" -a -n "${HAS_GTK2}" ]; then
DEPEND="${DEPEND} >=x11-libs/gtk+-2"
fi
#############################
If this was changed to DEPEND="gtk2? ( =x11-/libs/gtk+-2* ) !gtk2? ( =x11-libs/gtk+-1.2* )" in the eclass what could possibly break? You could even preempt a new bug by adding an equivalent RDEPEND in there as well so that binary packages don't break.
###gtk-engines-2.2.0.ebuild###
[ -n "${HAS_GTK1}" ] && DEPEND="${DEPEND} >=media-libs/imlib-1.8"
##############################
As noted earlier, this could be changed to "!gtk2? ( >=media-libs/imlib-1.8 )" and you get the same affect without the brokenness. That's all that needs to be done to fix this bug. Any packages that do break by such a change are broken already.
"And there are other ways to speed things up if thats your concern" That isn't the concern. The concern is that these ebuilds/eclass's are trying quite hard to cause dep resolution borkage on users systems and merge uneeded deps, and y'all don't seem to care. "you come with endless pointless criticism, while I have already made clear that we will accept reasonable working patches. But no, according to your 3 last comments I have to write patches for your packages broken behaviour and you also tell me to fix ours" This is standard policy that *new* devs are supposed to know. Violate the policy and introduce the possibility of dependency resolution failures/merging uneeded packages, I'll point it out when I see it and ask you to fix it (as I did for gtk-engine2 in bug #56218 roughly 2 months ago). Ignore continuing complaints to fix your broken ebuilds/eclasses, I will become irate, as will the users who wind up with crap packages merged that aren't needed (or even better, have a build bail because the deps the ebuild specifies to portage is incomplete). "Portage acts upon ebuilds, not the other way around." Wrong way of looking at it. Ebuild's run within portage's supplied env, and are expected to follow the conventions of the current versions of portage that are supported. If portage is limiting, we extend it, not ignore it. What you seem to be missing is that you can't just jam this stuff into the tree and then state "portage sucks, it's too limiting, not my fault"- you use the -same- portage as the rest of the community, further you're a dev- you're *supposed* to know this crap, and be proactive about QA. Instead, you're pointing the finger at portage when QA comes around complaining about your code. If you fixed it when it was first pointed out, instead of waiting until someone gets pissed off enough to jump your ass about it there wouldn't be these flame fests. Seriously, think about it for a sec- these ebuilds are merging unneeded deps, and you're not doing anything to fix it- you've had *ample* time to fix the gtk-engines2 issues, I filed bug #56218 on 07/06/04, detailing the problem and including fixes mentioned above. I'm not much for having to have these stupid little battles, and I'm not much for herd leaders ignoring -valid- QA problems, let alone having to get nasty with them just to get them to cleanup their mess. Just fix the stupid thing already. Can somebody please explain to me why we can't go off USE flags here? gtk != gtk1, but that's not a problem. gtk && gtk2 == gtk2; gtk && !gtk2 == gtk. That's how the gtk2 flag is defined. "Use gtk2 where a package supports both." So if only gtk is set then support both gtk1 and gtk2; if gtk and gtk2 are both set then support only gtk2. With regards gcc-3.5, gtk-1.2* needs fairly major chunks rewriting in order to avoid massive segfaulting problems with everything that links against it. And by "fairly major" I mean a few hundred lines at a time, several times over. gcc-porting is one of my hobbies - I always have my main gcc-3.4 system, plus a gcc-3.5 chroot for porting things, with the same world file. gtk-1.2* is not something I'm going to lose too much sleep over if I can get a system up without it. Finally, I personally believe that conditional deps should be completely banned: with regards dependency graphing, this turns a hard problem into an impossible one. Furthermore, there's absolutely no need for them. USE flags satisfy this problem. In this case, consider the following example: user does "emerge gnome" on a portage-2.0.50* system. imlib and gtk-1.2 do not get pulled in as dependencies, but gtk-engines-2 gets built. User then does "emerge package", where package depends on gtk-1.2. gtk-1.2 does not have gtk-engines support. gtk-engines does not get rebuilt. I realise I'm rambling a bit here. I've been awake for 21 hours on the back of 4 hours sleep and I've just driven 130 miles. So no, I won't apologise, I'll just try and put things more succinctly tomorrow instead... "Finally, I personally believe that conditional deps should be completely banned" Cond. deps -are- banned. That's why we have use flag support in depends. Not saying it's perfect, but it is what we have (and what can sanely be expanded). @ferringb : fyi this stuff was written & done like over a year ago. I think we even asked the portage devs at the time if it was ok to do it like this. I don't say it's correct, i say it should be correct. And your bug #56218 is still open, so it is being looked into. We have a lot more to do than to fix issues that are not problematic besides being seen from a strict QA pov, without any suggested solution (at least here we got one). Complaints without constructiveness. Anyway, the eclass is not 'my code' as you imply, if you had read it you would know. I know why it was written the way it is and you guys obviously don't & judge it for something that isn't our fault. This seemed the best solution at the time, if it's not.. fine.. but don't go hanging out your dirty laundry here & just propose a fix. As far as portage goes, as soon as ebuilds need to start hacking around portage deficiencies, there's something wrong. @ robmoss, we're not at gcc-3.5 , i'm not gonna lose sleep over things that aren't here yet. Gtk+-1 is not gone yet, how much you want it. There's still dozens of little apps using it & probably even ppl on slower machines having full installs. Wishing it away doesn't make it go away. As long as it is feasible I'd like to support, with your help or without it. but to get back to the bug ( i guess thats what this is meant to be about ) ? Anyway, bug #56218 clearly states the problem, the USE flags are not enough to do everything the user expect. They want both gtk 1 & 2 engines if available, regardless of keywords. It's not like the one is 'better' than the other, one is just for another version. So thats why jstubbs final suggestion (& comment #9 i guess) is not what we want here. *** Bug 56218 has been marked as a duplicate of this bug. *** ferringb: '"Finally, I personally believe that conditional deps should be completely banned" Cond. deps -are- banned. That's why we have use flag support in depends. Not saying it's perfect, but it is what we have (and what can sanely be expanded).' foser: 'I don't say it's correct, i say it should be correct.' Foser, not only is this not correct, but it also should not be correct. Have you really thought this one through? Think carefully about what a conditional dep really means in the bigger picture. In logical terms it introduces an inconsistency into any graphing method you care to devise, which is totally unacceptable under any circumstances. I've outlined a scenario in which conditional dependencies express their fundamental flaw above, but you appear to have ignored it, so I'll state it again: user does "emerge gnome" on a portage-2.0.50* system. imlib and gtk-1.2 do not get pulled in as dependencies, but gtk-engines-2 gets built. User then does "emerge package", where package depends on gtk-1.2. gtk-1.2 does not have gtk-engines support. gtk-engines does not get rebuilt. Thus, the conditional dependency "solution" is no solution at all. It cannot, and will not, ever work reliably and give the user what he/she "expects" (which is what you say you're trying to achieve) beyond the initial installation - and even then, it's dubious. The *only* way it is possible to fix this is by splitting the package, and by getting the dependency the correct way around. If you want to create a new "nogtk1" local USE flag to mask out gtk+-1.2 support, then fine, do that. It works, even if it's not ideal. It's a two minute job. If you want to split the package and have gtk+-1.2 depend on one version and gtk+-2 depend on another, then fine, do that instead. It's a more transparent, is less confusing to the user, is more correct, works, and will take perhaps an hour. And like I said before: if you want me to fix it, I'll fix it, but I need to know what in the hell you think is "acceptable" before I do it; otherwise, I'm wasting my time here. Finally, to go slightly OT again, gcc-3.5 is in stage 2 already, meaning its release will be in a matter of months. Theoretically, this should be around mid-November, but I can see it taking a bit longer than that - January 2005 is probably a better shout. However, considering the massive number of fixes required for gcc-3.4, I figured that starting work on this early would probably be a good plan, as 3.5 is an even more evil beast than 3.4. As such, this conditional dependency bug is a blocker for my work in this area: currently, I can't test gnome properly, as I have to use a hacked version of this ebuild and eclass which probably doesn't do what it's supposed to do. I don't *want* to have to profile-mask gnome in a gcc35 profile in a few months, but if you make me do so, I will. And then you can watch as all the bleeding edge compiler users (who constitute a non-trivial subset of our userbase) wander off to pastures new - such as KDE or, worse still, BreakMyGentoo. Okay, all, I have a good reason as to why conditional dependencies should never be implemented in portage. The reason for this is that it alters the problem of dependency graph generation from being a relatively easy problem (far easier than NP-complete) to being an unsolved problem (unless you don't mind your graph generation time increasing exponentially). I went and got a graph theory book from the library earlier on and had a read of it. As far as I can tell what I state above is true, although some of the concepts are a little beyond me - I'll let you know otherwise if I find out anything different. Guys, leave your aggression at the door. This is Gentoo, and you're expected to behave professionally. Re comment #24: "They want both gtk 1 & 2 engines if available, regardless of keywords." That just doesn't seem like the way it should be done. They seem ignorant of how to use USE flags properly, and a workaround shouldn't be created for them. Regardless of whether anyone agrees or disagrees with that argument, I'd like to know: If that is assumed, would Jason's suggestion in comment #20 work? Okay, I've tried to stay clear of this flamefest but It seems that I'm failing. Regards to gtk+ 1.2 and borkage with gcc 3.5 : Too bad, other issue, later issue. Go hide in the corner for bringing it up. No, #20 solution is not a solution. The problem is that we cannot use the !gtk2 dependency, becuase there is no "all or nothing" state here. Theese are the possible states: user has only gtk 1.2 -> installs theme engine user has only gtk 2.x -> installs theme engine user has both 1.2 and 2.x -> installs theme engine. Since, fex. "cleanice" is a theme avaiable for both 1.2 and 2.x, And the user wants -BOTH- if they have it. The Gtk2 USE flag cannot be used exclusively. if a user wants a theme for their desktop. they want the theme to be uniformly applied, thats why there are uniform themes. However, the hack here, is basically because we need a way to en/dis able the gtk 1.2 dependency. The current way was working, and was correct until caching started to work. (Oh, it violated -then- unspoken policy about best practice, Give or take. ) However, stricter requirements were enforced and noone has yet to come with a solution here. State machine for the whole thing is dynamic, I'd rather want to deprecate gtk+ 1.2 completely, add a USE="deprecated" flag and then trigger the gtk+ 1.2 dependencies with that, however, its not a satisfactory way either. SLOT doesn't work due to how versioning is handled, and because each theme has its own versioning requirements, basically sending you all down the yellow brick road of maggoty dependencies. And its not obvious to end users. gtk2 USE flag could perhaps be violated to not be an all or nothing, but to be addon, however this is unsatisfactory because it -forces- gtk+ 1.2 dependencies. then falls back to separating the theme engines, breaking our own policy of actually having versionnumbers in the themes. oops. not a good idea either. An idea is to simply kill the cache based on a key in the gtk themes eclass, and let portage live with the local slowdown. So, no. This issue is -NOT- solved, not by anyone in the current thread. This is very much like the deal with php and apache-[1,2]. You have two choices: 1) Create gtk1 USE flag and don't bother what is actually installed. Hence, DEPEND="gtk1? ( =x11-libs/gtk+-1.2* ) gtk2? ( =x11-libs/gtk+-2* ) !gtk1? ( !gtk2? ( =x11-libs/gtk+-2* ) )" 2) Wait until portage properly supports slotting packages based on other packages. See -dev thread entitled "Cross Compilation and Dynamic Slots". There is a slight difference between this case and the apache case, however. The apache2 USE flag has no relation to the apache1 USE flag. Nor do they have a dynamic DEPEND at all. What is wanted is clear to the user and could become clear to portage. In this case, however, there is presently no way to specify that gtk-1 support is required other than basing it on the fact that gtk-1 is installed. Portage has been designed such that USE flags are a flat namespace with no interdependencies. "gtk2" modifying the behaviour of "gtk" violates this and so is simply not supportable now or in the future. So, even with portage support as per #2 above, it could not be employed here because there is no way to specify slotting against gtk-1.2. I would suggest a "gtk1" USE flag but a "deprecated" USE flag would solve the issue just outlined. As for caching/dynamicness/whatnot, even if this wasn't "broken" way back when, portage could still not have known the information that it needed to correctly install the package. Take "emerge gtk-engines =x11-libs/gtk-1.2*" where gtk-2* is already installed for example. gtk-engines tells portage that it only needs gtk-2*. Portage installs gtk-engines and gtk-1.2*. Immediately re-running the same command at this point would yield a different result even though none of portage's parameters had changed. That is definately not what should be happening. And so no, killing the cache does not solve the problem. Going back to the two choices above, I think #2 is best for apache because the whole configure/make process needs to be ran for each version of apache to build against (although they could use #1 in the short term - but that's another story). However, in this instance, I think #1 is best because gtk-engines can build against both gtk libraries in the one run. If #1 is not possible, please explain why. Yeah, the gtk2 USE flag is a monstrosity And, I -really- don't want to pollute the gtk-- flags further with adding just another ambiguous flag here. The solution to a messy situation that users have trouble with is not to add more confusion. I'd rather just deprecate the gtk+1.2 and use the "deprecated" USE flag for this. However, I'm not comfortable with this as its not a proper solution, dynamic SLOT would be cleaner, and one I prefer to work with. The solution I would push at this point is to drop gtk1 support, since the number of gtk1 users is dwindling & I don't think it's worth the trouble at this point to rewrite the eclass to make everybody happy. The engines eclass just gets a has_version check in src_compile & only builds gtk1 engines if gtk+-1 is installed, probably some seperate engines ebuilds need to be fixed as well. Spiders solution of dropping cache for this pack -if possible- i consider not bad either, but i guess it's bad behaviour to do such things as well. In the bigger picture my idea of getting problems like this resolved is by introducing the concept of slotted USE flags. In this case you would have a gtk USE flag & you can select for which slots you want to support it or for all/maintainer-suggested if you don't select anything. Setting USE="gtk[-1,2]" would only get gtk 2 engines (in this case) to be built, etc. "The engines eclass just gets a has_version check in src_compile & only builds gtk1 engines if gtk+-1 is installed" Err... if you're proposing doing a has_version in src_compile, and enabling gtk1 support based on that, that would be a bad thing... DEPEND/RDEPEND -must- be accurate, and doing what you're proposing would leave RDEPEND/DEPEND incomplete. "Spiders solution of dropping cache for this pack -if possible- i consider not bad either, but i guess it's bad behaviour to do such things as well." It's bad. (see patch) :) Even if this approach was used, no version of portage currently supports it- backwards compatability would be an issue. "Setting USE="gtk[-1,2]" would only get gtk 2 engines (in this case) to be built, etc." No different then adding a gtk1 flag now, and doing USE="-gtk1 gtk2" Either way, adding a gtk1 flag to control if gtk1 support is built would work imo. Added, it would also be a step towards removing the gtk/gtk2 goofyness. Don't suddenly pretend you are worried about the depgraph, this is a problem because it doesn't work with the current cache & nothing more. has_version is used everywhere in the tree, it's a whole different crusade to get that thing going if it really bothered you. @ the USE flags comment : creating a gtk1 flag is as much a regression & a backwards compatability problem as you are worried about when disabling the cache (which wouldn't be so troublesome, because most ppl already have no problem using the eclass as it is). Anyway it isn't even close to being the same thing, think about it. "Don't suddenly pretend you are worried about the depgraph" Foser, this whole thing has been *about* the dependencies being wrong/invalid (what you're labeling depgraph). "this is a problem because it doesn't work with the current cache" Adding a gtk1 use flag works fine, fits within the current standards of the tree, and gives the users what they want (ability to avoid the gtk1 deps). The problem isn't portage/cache, it's in the approach to the problem. As for has_version being abused in ebuilds, yes, aware of it. If I see ebuilds specifically using has_version to link (note link) in support, then I file a bug (because the RDEPEND/DEPEND isn't complete). "creating a gtk1 flag is as much a regression & a backwards compatability problem" Not everyone agrees with you, so please explain -why- we're wrong. Don't just state we're wrong. "when disabling the cache ... which wouldn't be so troublesome" Foser, the cache will -never- be disabled in an instance like this, alright? The issue of controlling what support is merged (gtk1 || gtk2 || (gtk1 and gtk2)) -can- be specified via the existing DEPEND syntax and the addition of a gtk1 flag. The cache -will never- be disabled in such an instance, the problem is in the approach and willingless to implement a solution within the available solution domain, alright? actually, as far as I know, a lot of the gkrellm plugins ebuilds suffer a similar conundrum -- a "gtk1" or "deprecated" USE flag would be helpful in those cases as well. It seems like none of the solutions presented makes everyone happy. "gtk2" as a USE flag is a monstrosity, as Spider has noted. It caused confusion (recall the -dev/-core thread that Spider had to write) before and it does right now. This stage in the game, we can't conceivably change it too much, however, adding either "gtk1" or "gtk-old" or "deprecated" (the last can probably be extended to other non-gtk cases as well; this is a virtue) would make things a lot simpler. What will it take to get this fixed? Gnome dudes? Portage dudes? Seriously, what can we do? Whatever it is, blame me. Or hell, make me do it :) Talk to me people. To fix this, a decision on what to do USE flag wise is required. Do we use deprecated, gtk1, gtk-old, etc. Portage won't be modified to disable the cache for these ebuilds since the existing DEPEND use syntax is more then sufficient for these ebuilds. Basically, y'all need an additional flag to use in depends syntax. Seemant, see comment #32 as that is mostly flamefree ;) Adding a "gtk1" would just be the same as gtk2 all over again. And then we also come back to that whole thing with "versions in names" Which we seriously want to avoid. Adding "deprecated" USE flag has a lot of other virtues, We problably want to do this for Gnome 1.4 support in software too ;) DEPEND="deprecated? ( gnome? ( gnome-base/gnome-libs ) )" or such would make a lot of people happy. ;) However, this would also cause ambigousity along the line, since we will need a -clear- policy on what to consider deprecated and what not. Values and supportlevels have to have a meaning here. When is software support deprecated? gtk+ 1.2 is, has been for several years, it continuously breaks on architectures, yet a lot of software depends on it. Deprecating it has been painful to say the least, and software is -now-, around.. what, 4 years later, still just beginning to convert over towards it. A lot of software hasn't even started yet. "important" software (gnucash ... ) However, knowing the full implications of pain inquired with gtk+ 1.2 theme engines, I'm inclined for this suggestion: ignore the USE flag ideas for gtk+-1.2 deprecate the gtk+-1.2 -engines- override and just install the themes. I'd suggest to introduce a "gtk1" flag, as there *might* be people who want a gtk1-based system (note that there still exist many packages that don't -- and most likely never will -- have gtk2 support at all, mostly commercial ones). @foser: This gtk/gtk2 USE flag stuff is broken by design. Furthermore its used inconsistently throughout the tree. It pisses off many other users I know. Only because few of them complain about it in Bugzilla, it doesn't mean that it isn't an issue. I filed several bugs on this (most of which quietly disappeared) with thorough debugging information and a clear statement what's wrong. I tracked down the issue by hacking the ebuild/eclass myself and notified the maintainers (both via email and bugzilla). I brought this issue on topic at IRC and I try to get attention on this for almost 10 (sic!) months -- but noone seems to care. At some point I stopped because it looked like I was being ignored. It's nice to see that *finally* someone seems to care. So please fix it. Soon.
@ OFFTOPIC post:
> This gtk/gtk2 USE flag stuff is broken by design. Furthermore its used inconsistently throughout the tree.
It was meant for a shortterm passing of software with alternative interfaces, as such it actually works, but is deviant from other USE flags in its exclusive nature. This is bad.
There is no inconsistency about this in the tree however, unless it has been added recently.
Now PLEASE get back on topic darnit!
I'm willing to close this bug as WONTFIX: FLAMEFEST, and reopen the issue in a nother bug id.
First, GTK1 support cannot be dropped simply because of the number of packages that use it (gnucash, idesk, enlightenment) so that would be a shot in the foot. Since we need to keep it around, what are the solutions? Answer this question based on the portage ebuild guidelines: Are you allowed to have versions in your USE flags? If so, gtk1 as a USE flag, even if local, is a viable alternative. Yes, it will add some confusion at first but if we go with just gtk1 and gtk2, instead of a generic gtk, it clears up the inconsistent use of gtk and gtk2 as it stands now. If not, gtk2 is already an invalid USE flag and gtk1 should not even be a thought. It's the broken window concept from PragProg, one bad case will perpetuate. In that case, it needs to come down to a single gtk flag building with the appropriate version, and if there is support for both, doing ONLY gtk2 as that has wider compiler support. If that leaves the gtk1 users out in the cold, then that comes down to a necessary change in portage practices being needed, not in the ebuilds. I definately agree with Rob and Brian as we need to go with best practices over what's easiest to implement. The dependency graph for any package should be easy to determine and not fluid as it is in this case. What it comes down to is what are the solutions that fit into the portage guidelines? (Not what solutions have been used in the past) I for one run a gtk2 only system and I have to modify the gtk-engines2.eclass (simply adding a space to a blank line) every time I sync so I don't get imlib and gtk1 and would like to see this fixed as soon as possible since I've been waiting months. Foser, for what it's worth, this is the only package/eclass/whatever in the tree which throws up a "has_version in global scope" when you attack it with repoman. It also complains about the SRC_URI being incorrect, but that's one for a different bug (which may never need opening, so I won't, yet). Anyway, I'm hearing what you're all saying about gtk+-1.x support needing to stay, but I'm not too sure I agree with it. Gnucash has a gtk-2.x port in progress, by the way, for those of you who didn't know (I had a CVS ebuild somewhere once, but it was a good few months ago in the early stages of development and didn't even build). Sure, it needs to be an option, but we can support it without forcing it on people. It should be installed if and only if a package explicitly depends on gtk-1.x but cannot use gtk-2.x, perhaps only when the "gtk2" USE flag is not set. I honestly think this is fixable, and the nine eclasses that use has_version, plus the 302 ebuilds (thats ebuilds, not packages), should hopefully be (where necessary) fixable too. I quite like having a well-defined dependency graph, and right now I can't have one :( It's not only gtk-engines that has this problem - but gtk-engines appears to have it "worst" (sorry, there's certainly a better word to put in there) so before I go on a depgraph crusade I'd like to stick around for the outcome of this one. That said, I agree with the idea that a big rethink of the whole gtk/gtk2 mess is required - for another example of gtk-engines related messyness, take a look at x11-themes/gtk-engines-lighthouseblue/gtk-engines-lighthouseblue-0.7.0.ebuild. We have a similar problem with multiple language support. I just experienced this: checking for imlib-config... no checking for IMLIB - version >= 1.8... no *** The imlib-config script installed by IMLIB could not be found *** If IMLIB was installed in PREFIX, make sure PREFIX/bin is in *** your path, or set the IMLIB_CONFIG environment variable to the *** full path to imlib-config. configure: error: *** IMLIB 1.8 not installed - please install first *** !!! ERROR: x11-themes/gtk-engines-2.2.0 failed. !!! Function econf, Line 362, Exitcode 1 !!! econf failed Portage 2.0.50-r10 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.7-gentoo-r11) ================================================================= System uname: 2.6.7-gentoo-r11 i686 Intel(R) Celeron(R) M processor 1300MHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe -ftracer -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe -ftracer -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache prelink sandbox" GENTOO_MIRRORS="ftp://ftp.rhnet.is/pub/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://ftp.rhnet.is/gentoo-portage" USE="X aalib acpi alsa avi berkdb cdr cups dga dvd encode esd faad fam fbcon flac foomatidb gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml imlib jpeg mad mmx mmx2 moznocompose moznoirc moznomail mozsvg mpeg ncurses network nls nvidia offensive oggvorbis opengl pam perl pic png pnp python quicktime readline rtc samba sdl sse ssl svg svga tcpd truetype unicode v4l v4l2 wxwindows x86 xml xml2 xv xvid xvmc zlib" `emerge imlib` took care of that ofcourse. What's going on with this bug? The last gnome member to comment was a week ago. This still is borked, and needs a proper fix. Well, What is there to say here? There is no satisfyable solution for this. My vote still goes for "deprecated" USE flag triggering the gtk1.x deps. Alternatively removing gtk+-1.x theme engines from the tree alltogether. (not a good solution. but it might not make as much of an impact as we fear, and its a good first step towards deprecating gtk+-1.2 completely) Creating a "gtk1" USE flag is out of the question. Terminally so. Auto-SLOT'ing might be antoher idea, SLOT="1.2" for gtk+-1.2 and SLOT="2" for gtk+-2.x engines. Then we'll have to maintain a -r1 and -r2 of everything, and create a hassle of that, however it would clean out the depgraph, and put the pain onto the user instead :( A "deprecated" USE flag would solve this. I, personally, think that a "gtk1" USE flag would be more aesthetic though. Why exactly is it out of the question? Because it would basically be the gtk2 flag -all over again- and we all know just how much confusion and ambiguosity it has caused over the time. Now with a gtk1 there would have to be logic-order policy, and for a set of developers who can barely differ 1 from 2 in some cases, I have no hopes in getting this right, even less hopes in them getting it consistently right for our users. Okay. That's fair enough. So you will do the "deprecated" flag then? Not that it's entirely relevant to this bug, but a "deprecated" flag will also have the priority/selection issues should another forwards/backwards incompatible gtk happen to come out. Aye, I could. Checking with Gnome lead. *hmpf* foser: ok with you to go for "deprecated"? Status? I'm not in favor of a 'deprecated' flag because its so subjective by nature & i fear it will be (like the gtk2 flag) used way beyond what it was meant for & create similar situations in the future. I'd say we shouldn't go down that road again. I think my solution is still the best to just build no gtk1 engines if the gtk1 package is not installed. It is not harmful in any way (like the current solution used to be), only the depgraph might not be completely correct at times. I see this as the shortterm & not the perfect solution, longterm there should be a portage wide solution to deal with these situations in a satisfactory manner. Some suggestions to how that could be done have already been proposed. Until then, my proposed fix should do just fine. Foser, that doesn't work. Seeing as how gtk-engines doesn't ever get rebuilt as revision bumps simply don't happen for this, if gtk-engines is built before gtk-1, then your conditional dep means that gtk-engines will NEVER get the gtk-1 stuff built. Any of the other solutions is preferable to this - even a "idontwantgtk1supportforgtkengines" local USE flag would be better. thats a known consequence yep & bumps do happen. Actually we usually suggest a engines rebuild on gtk+ minor revisions, so rebuilds happen anyway. Few ppl seem interested in gtk+1 support anymore reading this thread, yet still thats the major rejection point all of a sudden ? And local USE sillyness isn't preferabble anywhere, anytime & it wouldn't be local anyway. Foser, the issue is not a lack of interest in gtk+-1 support, the issue is that the behaviour is inconsistent and violates policy. I thought you were something of an avid supporter of QA? I still haven't worked out why splitting the package into gtk1-engines and gtk2-engines isn't acceptable. Care to explain? There *are* two entirely seperate, non-interdependent packages in there being compiled to give support to two entirely seperate, non-interdependent packages. Ergo I don't think these should be part of the same package. I really don't understand half of this thread, and I still dont understand why we didn't/don't move to a heirarchy of USE variables where if USE="gtk" then IUSE="gtk1 gtk2 gtk3 etc..." but you seem to have your reasons. At least though could you put a comment in the gtk-engines ebuild telling me to touch the darned ebuild after I sync. Every damned time I sync up and try to emerge -upD world I get this stupid gtk1.2 problem. It only takes a few minutes to figure out it is coming from the engines but in theory HAS_GTK1 should prevent my problems -- which brings me to bugs.gentoo.org. Please just put a comment in there so I won't have to resort to searching bugs and the forums again. Thanks, D Offtopic: Following up on my previous...
I just noticed the local flag no_wxgtk1 which you can easily imagine its function. This appears to me to be a flagrant violation of the meaning of gtk2 flag but evidently the developer wasn't comfortable forcing people to use the unstable wxGTK2 just because their gtk2 flag indicated they wanted things like xchat in gtk2. So we essentially have a -gtk1 flag already, it just happens to be local and have the meaning of the proposed three flag "gtk -gtk1 gtk2".
I can understand some reservations about switching to a multiflagged system like this since it would require changing a number of ebuilds and alerting users (I'm sure I'm not the only one happy to do the grunt work of fixing ebuilds for a gtk1 flag). But, Foser, Spider, do you at least agree that it would have been the way to go? This whole thing gets so frustrating because it seems you don't want to recognize that a mistake was made when the gtk2 flag was created without a sister gtk1 flag. If you had just looked at the work and said "We screwed up, we know it, the fix is obvious, but ( its too much work to change the ebuilds | publicizing a policy change at this point is impossible )."
Ultimately I don't care what is done as long as -something- is done to correct this (and the has_version src_compile check is still wrong). Foser/Spider, why not just introduce versioned flags, and convert the meaning of gtk to flip on whatever version of gtk the app prefers. fex, using xmms- IUSE="gtk gtk1" The user can flip on either gtk (general flag enabling support, whatever the src prefers), or flip on gtk1 only. Better example, assuming mplayer still had the gtk2 support, IUSE="gtk gtk1 gtk2" If the user specifically wants to control the version of gtk that's used, they can via the enumerated flags. Otherwise, they flip on gtk, which is per package whichever gtk version the package wants. Yes, these flags are in the tree already, and yes, this does involve work (I'll do the damned conversion just out of the principle of killing that gtk/gtk2 flag setup off, as might others I'd suspect). In terms of migration, assume most users are after gtk2 at this point- migration wouldn't be bumpy for them since they already have gtk (let the package choose the version) and gtk2- they've specified they want v2, and let the package choose- as we're going through changing the implications of the flag from the current setup to versioned flags for each package, we just set gtk in that package to specify v2 as default (with xmms being the weirdo that is DEPEND="gtk? ( =x11-libs/gtk+-1* )" Granted the flags/depends can get annoying, but it breaks the problem down and gives y'all the flexibilty so that you're able to specify your depends in a -static- way to portage (as this bug has demonstrated a need for). Err... gnome crew, you going to do something about this? It's pushing 3 weeks... may not like the deprecated flag, but I'd suspect users don't like the crap deps either :) I can understand people are busy, but there are quite a few ways this can be corrected (literally choose your poison)- it can be corrected by adding a single local flag, or a restructuring of gtk/gtk2 which seems saner long term. Meanwhile, adding a local deprecated use flag would clean up this mess. Kindly do something about this, it's been open way too long, and it's getting old asking y'all to fix this. given that i'm the culprit in most of this, i should probably speak up. i totally agree that the dependency hack was an ugly hack at best. i've never had enough time to sit down and fix this properly, and i don't think anyone in the herd especially likes dirtying their hands with that stuff. the only viable fix i can see here is to just split the all the hybrid packages into gtk1-engines and gtk-engines. the slot system doesn't help us here. we've tried that before and it just made things messier because of the fact that some engines have a gtk2 version, some engines have a gtk1 version, some engines have both. imho, adding useflags only confuses the situation here. anyway, once i get some time (that is that i can even get through some higher priority bugs), i will try and address the problem, or i would greatly appreciate anyone who can help with this. *** Bug 60085 has been marked as a duplicate of this bug. *** What's going on with this? Can a final solution finally be reached here? I'm getting awfully tired of having to touch the ebuild everytime I emerge sync...I don't mean to come off impatient or add fuels to the flames here but this bug is over a year old at this point. I don't see a problem with either of the proposed solutions, and seeing as the ones proposed are really the only ways to go short of modifying portage, I don't see why one of them can't be implemented. Found again when emerging gtk-engines on 2004.3 amd64. Please fix this sometime in the next decade. This is a bug in the definition of a bug is a functionality that suprises the user. Programs should do exactly as the user expects them to behave (assuming the user is informed on their intended functionality, ofcourse). I've had the same problem emerging gnome-light after a fresh gentoo amd64 2004.3 install. imlib should have been a dependancy but wasn't. i emerged imlib and everything went smoothly I don't really used the best research USE flags, but here they are USE="apache2 gtk gtk+ gnome X gdm -qt -kde dvd alsa -oss xvid java postgresql -cups -multilib nptlonly" *** Bug 66113 has been marked as a duplicate of this bug. *** Created attachment 46998 [details, diff]
A posible solution
This patch only require imlib when not installed gtk2, in gtk2 imlib is not
required.
Solve the problem when install gentoo in first
Same problem there. That DEPEND will be cached, and therefore hardcoded on most users systems and never even considered as evaluated. Only 326 or so bugs that are older than this one... more than half of which are enchancements. Cool. Just keeping the bug alive. Found once again with gtk-engines-0.12. Having my emerge crash every time i do a fresh install is getting a bit old. Created attachment 49902 [details, diff] 2.0.51-r15--recache_restrict_flag.patch Just for completeness of the possible solutions exploration, here is a simple Portage patch that adds support for a "recache" RESTRICT flag. Setting this flag in the gtk-engines2.eclass would have the effect to force a cache entry regeneration for GTK engines ebuilds during the dependencies calculation, making it work as expected without any other modification. Since it only affects a very few packages, and is done only once per ebuild, the speed impact is negligible. I perfectly realize it's not the ultimate solution tho, more "yet another possible quick hack that would allow installing a gtk2 theme without installing gtk1". I've already discussed a similar patch with Nick some time ago for a different issue in bug #32367, and his objection about broken binary package would also holds here. Oh, and it would not hide this ugly QA notices for the user (but that's a different problem, and imho this notices should simply be all hidden when you don't have some kind of i_am_a_dev FEATURES flag set in make.conf). No. Dependency calculation *requires* that any dynamicness works within a set of specified rules. RESTRICT="recache" means that there are no rules and ebuilds would be free to arbitrarily set whatever whenever. Yes, we could say that "recache" can only be used in conjunction with certain variables, but this bug certainly shows that the rules wouldn't be followed anyway. Actually, this patch wouldn't fix anything. If the user does something like "emerge =gtk+-1.2* gtk-engines" the ebuild would still give incorrect dependencies during dep calculation and fail when gtk-engines is actually built. > ebuilds would be free to arbitrarily set whatever whenever. Not exactly "whenever", only before being integrated into the deps tree, and then it won't change anymore. It is not that different than having several different ebuilds available (for instance a something-gtk1, a something-gtk2, and a something-gtk1-and-gtk2) and emerging one in particular. And for the "whatever", well, sure, such a feature should be used with much care, etc. I would not even vote for talking about it an the ebuild manual or anything, that would really only be a hack for some exceptional cases, and only for people who know what they do. Just like dynamic slots for apache modules. > Actually, this patch wouldn't fix anything. It fixes the major issue which is that, at the moment (well, since months actually), an average user who don't know about portage internals can't install a gtk2 theme without also installing imlib and gtk1. > If the user does something like "emerge =gtk+-1.2* gtk-engines" the ebuild > would still give incorrect dependencies during dep calculation and fail when > gtk-engines is actually built. That's true, but how often will that happen, compared to the actual troubles we have now? And btw, changing the "has_version =gtk+-1.2*" into a "has_version imlib" for the HAS_GTK1 test would probably be enough to ensure that the package builds fine in all cases, despite its wrong deps. That said, i don't want to push that feature more than it deserves, and sincerely, i understand your objection and your points are very true. I knew before sending this patch what were its drawbacks. My intention was simply to add a bit to the brainstorming, because while reading the comments above i've thought that the "having dynamic depends would slow down portage 400 times" was unfair. Now, if you tell me that adding a gtk1/no_gtk1/deprecated/whatever USE flag is a better and cleaner fix, i can only agree. Or splitting the ebuilds, i don't care, i would just like to see something done because this bug is a major annoyance. > ebuilds would be free to arbitrarily set whatever whenever. Not exactly "whenever", only before being integrated into the deps tree, and then it won't change anymore. It is not that different than having several different ebuilds available (for instance a something-gtk1, a something-gtk2, and a something-gtk1-and-gtk2) and emerging one in particular. And for the "whatever", well, sure, such a feature should be used with much care, etc. I would not even vote for talking about it an the ebuild manual or anything, that would really only be a hack for some exceptional cases, and only for people who know what they do. Just like dynamic slots for apache modules. >> Actually, this patch wouldn't fix anything. >It fixes the major issue which is that, at the moment (well, since months >actually), an average user who don't know about portage internals can't install >a gtk2 theme without also installing imlib and gtk1. Not really. In reality, this is a kludge to portage to fix broken ebuilds (broke at the time of initial commits). Being harsh, but stating it as it is mainly since portage -should- not be modified, since no other ebuild has forced a requirement of such functionality. Additionally, the connotations of it suck- if the cond. DEPEND setting of a recache restrict ebuild is based on xyz being merged, at the time of the depgraph's creation, xyz isn't merged but is planned to be, the resultant DEPENDS in the recache restricted ebuild is still wrong (as point out by jason). Basically, it's not a proper fix, nor would adding such a fix really be feasible. :) >Now, if you tell me that adding a gtk1/no_gtk1/deprecated/whatever USE flag is >a better and cleaner fix, i can only agree. Or splitting the ebuilds, i don't >care, i would just like to see something done because this bug is a major >annoyance. Splitting the ebuilds, or adding use flags would solve this as stated above. Basically, there are ways to fix this without modifying portage- those methods should be used. Modifying portage shouldn't be done for a single package unless there is a -really- damn good reason to do it :) The issue thus far (my opinion) pretty much seems to be, which route to go. Portage crew can't really state which way to go, this is gnome herds decision. That said, something needs to be done about this, rather then it languishing. Don't really care if the end solution is distasteful, the current solution isn't acceptable. So... how do y'all prefer to address this within the valid options? Is there a chance in getting this resovled quickly? I only ask because we are running into this on the LiveCD, and I either require a fixed ebuild, or I'm just going to add imlib to DEPEND myself in the snapshot, which is a bad idea if it isn't what matches the actual tree. *** Bug 82310 has been marked as a duplicate of this bug. *** *** Bug 90589 has been marked as a duplicate of this bug. *** *** Bug 48348 has been marked as a duplicate of this bug. *** *** Bug 90964 has been marked as a duplicate of this bug. *** Just wanna know the progress of this bug. It opened two years ago, now I installed a new gentoo system, still cannot successfully build Gnome thanks to this bug. (to repeat: instal new gentoo, ACCEPT_KEYWORDS="~x86" emerge =gnome-2.10) I just worry the entry gentoo users who do not know portage mechanism would waste time on trying to workaround this bug, and even experienced people may waste time by starting emerge in the night and wishing to work on gnome in the next morning only to find an error message. *** Bug 93687 has been marked as a duplicate of this bug. *** Yo... status? Status of this? I've a circular dependency: Had GTK1 installed and installed gtk-engines, which depended on imlib which depended on gtk1. Even when don't have any gtk1 apps installed anymore, portage won't remove gtk1 since imlib depends on it and gtk-engines depend on imlib. *** Bug 100350 has been marked as a duplicate of this bug. *** Can *please* someone say if there is *anybody* working on this? Why don't just split the ebuilds, is this such a difficult thing to do? x11-themes/gtk-engines and any other ebuild previously inheriting from gtk-engines2.eclass has been modified to behave like regular packages. No more has_version voodoo. So, this should be fixed now. I apologise for leaving this bug unattended for so long. |
