A very ugly bug imho. Talked with ferringb and swegener in #gentoo-dev about it. Ebuilds which set only DEPEND are expected to get a RDEPEND=$DEPEND by portage. But this doesn't happen if an used eclass sets RDEPEND. As a result only the eclass runtime dependencies are stored in /var/db/.../RDEPEND. Reproducible: Always Steps to Reproduce: 1. 2. 3.
copy & paste: [22:00] <ferringb> Carlo: some specifics on that, looking at what I have locally, the change occurred between .47 and .49 [22:00] <ferringb> so the behaviour isn't new
Wrong, the bug we were actually talking about is: If an eclass only sets DEPEND, the dependencies won't be added to RDEPEND automatically. Currently an eclass has to set both to get the dependencies right. There are some eclasses which rely on the behaviour that portage sets RDEPEND="${DEPEND}" automatically if RDEPEND is unset, like portage does it for ebuilds. I think that the portage code should be changed to do it for eclasses too.
>Wrong, the bug we were actually talking about is: If an eclass only sets DEPEND, >the dependencies won't be added to RDEPEND automatically. No, that's incorrect. My example is digikamplugins-0.6.2.ebuild, which sets no RDEPEND, but inherits kde.eclass, which inherits kde-functions.eclass. Both eclasses set runtime dependencies.
Ugh wait, I think this is just another need-{kde,qt}() side effect. Ebuilds which use these eclass functions never have empty a RDEPEND, which means each runtime dependency (if not added by an eclass) has to be set explicitly.
Set them explicitly. It's much easier. I'm not entirely certain what I should be addressing with this bug report. Takes too much effort to weave in and out of the creativeness of developers.
Nicholas: I'm not 100% sure what Sven's problem is, but it's definitely a problem, that the need-kde/qt functions from kde-functions.eclass add runtime/dependencies to the ebuild dependencies. If the ebuild writer only sets DEPEND and not RDEPEND inside of the ebuild, because he relies on Portage setting RDEPEND=$DEPEND in this case, then only the runtime dependencies set by the need-kde/qt functions are stored. You are affected by this problem (at least if you run qt/kde stuff) and as you may have seen, I sent out an email ~24h ago regarding this topic. If you don't like to see this as a Portage bug and Sven doesn't disagree, please reassign to kde@gentoo.org, but this problem can only be properly solved with your help.
>Set them explicitly. It's much easier. Almost overlooked this sentence. This is possible, but it should be a policy for all ebuilds then. Ebuilds writing gets only harder, if we have a lot of extra rules for distinct subsets of ebuilds. I would favor this.
> Set them explicitly. It's much easier. I agree that this answers the initial report, the need-kde issue remains, though. Carsten, could you consider the possibility that need-kde/qt add dependencies to E_?DEPEND instead of ?DEPEND, this would be exactly equivalent to them being set directly by the kde eclass. Otherwise the problem with ebuilds setting only DEPEND remains, and could be addressed for instance with the first patch in bug 50721.
It's not particularly a portage bug, but I guess it will have to become a policy bug. I will probably make the effort to push explicit DEPEND strings and not have anyone assume portage will do it for them any longer. Eclasses should never assume this anyway. The creativeness comment was regarding how developers can always find a way to break something by doing something weird that ends up having a side effect in something else they are doing. This will be a lot of QA. Make the eclasses explict for now.
>Make the eclasses explict for now. This last sentence let me assume, you didn't really got my point. Because of these damn need-* functions the R/DEPEND in the ebuilds, which use them, have to be made explicite; I want to deprecate these, but I'll do that a while after portage .51 (<- big pointer ;)
> Because of these damn need-* functions the R/DEPEND in the ebuilds, which use them, have to be made explicit Why not applying the patch in bug 50721, or make need-* set E_DEPEND/E_RDEPEND instead of DEPEND/RDEPEND?
I don't think your patch is a good idea Gregorio, because it still involves the eclass function call to set the dependencies, after the eclass is evaluated. Also I would like to add the possibility to have operators. E.g. NEED_KDE="<=3.2" The usage of a variable has the disadvantage, that is has to be set before "inherit", but I think that's better, than having to call need-kde after R/DEPEND in the ebuild. I'm not sure about E_DEPEND/E_RDEPEND, but it's at least not "official" to use them.
Agreed that the patch is not the best solution. But please consider a bit more the possibility to set E_DEPEND/E_RDEPEND in need-kde/need-qt. It is what the eclass did a lot of time ago when it used "newdepend" (that function did quite the same thing), the dependencies would be added just like they were added by "inherit kde". It will make _all_ the ebuilds using kde.eclass instantly have correct dependencies, here and now. Every other solution forces you to modify about _395_ ebuilds! I think such a big job can only be justified by a new implementation that shines for its elegance, and my opinion is that this is not the case. The possibility to specify more restrictions for the kde dependencies could be added with no pain inside this framework. However, that's just my opinion! Thanks for your work!
All the discussion I've heard has indicated quite strongly that this won't be fixed (unless it wants to be resent to docs?)
Current behaviour (broken for eclasses) is intended on being left, next EAPI will have all RDEPED=${RDEPEND-$DEPEND} behaviour yanked.
