* To enable ldap USE flag, you need dns USE flag to be enabled * Please, enable dns or disable ldap * To enable ffmpeg USE flag, you need pipechan USE flag to be enabled * Please, enable pipechan or disable ffmpeg * Please see messages above and re-emerge ptlib accordingly. * * ERROR: net-libs/ptlib-2.6.2 failed. * Call stack: * ebuild.sh, line 49: Called pkg_setup * ptlib-2.6.2.ebuild, line 148: Called die * The specific snippet of code: * die If a USE option cannot be enabled because another option is disabled, then simply disable it and warn the user about it, but don't die. Also, provide a die message.
phpconfutils.eclass might be a good guideline here - die only if there is a conflict between USE flags, and not when one USE flag is needed for another to be enabled.
Created attachment 196656 [details, diff] Don't die, disable configure options instead There's a good chance I missed a few things here, but the basic idea is there. I adapted the use_disable() function from the use_enable() function in ebuild.sh from sys-apps/portage-2.2_rc33.
Comment on attachment 196656 [details, diff] Don't die, disable configure options instead Actually, this sucks too. When something is disabled because of a missing USE flag, you don't want to read about it in the die message, but you don't want to have to follow the scrolling output and having to stop it either, so when some configure option is needed for another configure option, the former should be (verbosely) enabled so that the latter can be satisfied, instead of disappointing the user multiple times, as in: 1) For A you need B. 2) For A you need C too. 3) You need D for A now. and so on.
I know this solution is not ideal but your solution leads to something I don't want. For example, with your solution, according to your error messages, portage will recognize your ebuild as built with "+ldap -dns +ffmpeg -pipechan" but, in fact, ldap and ffmpeg willn't be built. This is an issue or USE-dep: if foo needs ptlib[ldap, ffmpeg], portage will agree but in fact it will not work. My opinion is we need conditional use flags management in portage but it's not easy to do...
(In reply to comment #4) > I know this solution is not ideal but your solution leads to something I don't > want. > > For example, with your solution, according to your error messages, portage will > recognize your ebuild as built with "+ldap -dns +ffmpeg -pipechan" but, in > fact, ldap and ffmpeg willn't be built. Yes, and I already said so when I obsoleted the patch... The reverse mechanism is clearly the better solution, where options are turned on when and as they are needed by other options, instead of silently disabling desired options. Since actively disabling stuff is what your original ebuild is all about, I presented that solution. Rewriting it to do the opposite is easy enough. > This is an issue or USE-dep: if foo needs ptlib[ldap, ffmpeg], portage will > agree but in fact it will not work. > My opinion is we need conditional use flags management in portage but it's not > easy to do... In fact, we've been doing this for years and we don't need changes to package managers in order to achieve this.
(In reply to comment #5) > Yes, and I already said so when I obsoleted the patch... Sorry, I didn't see that and I probably answered just after reading your patch. However, even if better I don't see your solution as a real solution. To re-use my previous example, if I build ptlib with USE="ldap -dns ffmpeg -pipechan", i will actually get --enable-ldap --enable-dns --enable-ffmpeg --enable-pipechan even if I decide to disable dns and pipechan. I admit having something enabled when you wanted it disabled is better than having it disabled when you wanted it enabled. Unfortunately, it's possible to depend on ptlib[-dns, -pipechan] and portage will think it's ok because portage thin ptlib is built without dns and pipechan support. I'm not against auto-disable something but I'm against letting portage think the packgae is built with some USE flag even if it's not the case. It wouldn't be a big issue for a end-user application but for a library, it can leads to some issues. In my opinion there are four solutions: - portage should be able to disable/enable a USE flag based on another USE flag value - I try to auto-enable/auto-disable every USE flag needed by another USE flag - I try to merge two options - breaking when their is a conflict between two USE flags First one is surely not for a near future. Second and third a really hard to get. I tried and some conflicts can be avoided (for example, the two you mentioned) but not every so it's not solving our issue. In my opinion, the last one is safe and working right now. And, by the way, I'm printing every conflicts so the user can fix his 'portage.use' only one time. In addition, I think this method will be smoother with pkg_pretend which will come with EAPI-3.
I've added the die message to ptlib ebuild. I've also added opal in bug summary as I've also added this behaviour to opal-3* ebuild.
Got bit by this... I guess none of us are used to such behaviors anymore
@volkmar: Please see it this way. Entire teams have gone before you that have chosen a way to arrange USE flags in such a way that the user gets what he asked for. If USE=foo requires --enable-bar, then so be it. If you require the user to know how this package's ./configure works, then you're actually moving away from established Gentoo practices. I didn't point out the PHP example for nothing: with so many interdependent USE flags, that team ultimately found a way of 1) honouring all USE flags as asked by any user, and 2) dying only when USE flags really conflict. This doesn't require new package manager features, just common sense: you don't want to have users find out the right combination of USE flags through trial and error, which practically means calling emerge multiple times and letting it rip beyond the dep calculation stage.
I have been told to come here and yell at this bug. So here I am. YOU STUPID BUG AHHHHHHHHH!!! But, seriously, comment #9 sums it up. By analogy, what if you had to manually install PACKAGE dependencies? Say, you try to emerge mozilla-firefox and it dies because it requires xulrunner to be installed. How annoying! Hence, the very purpose of portage is to figure this stuff out for us. If ffmpeg functionality depends on pipechan, the pipechan functionality should be enabled by (ffmpeg|pipechan). Consider whether the latter really needs to be a USE flag. (I don't know the specifics of this case, but I'm speaking in guidelines.) If you think in terms of usability and user-friendliness, it's really quite obvious. =]
For opal, it's fixed in 3.6.4-r1.
Some options have been forced in ptlib-2.6.4 and for the last incompatibility between USE flags, it's not throwing an error anymore but a warning...
