Ebuild restrictions of many KDE 4.2 packages are inconsistent with dependencies specified by KDE. Examples: - Kopete-4.2 - OTR support internally depends on libotr 3.2.0+. If I enable otr USE flag, ebuild does not enforce libotr 3.2.0 installation (it is happy with 3.1.0, which is not accepted during Kopete build) It goes on... Reproducible: Always Steps to Reproduce: 1. Remove all KDE 4.2 packages from the system. 2. Start emerge @kde 3. Watch information about dynamic dependency discovery during build. 4. See inconsitences between what you have installed, what ebuild requires and what build finds. Expected Results: Ebuilds should reflect optional dependencies in USE flags, version requirements stated by the KDE package and by matching ebuild should be same. In my opinion it is impossible to cover all dependencies properly, because I've seen some circular dependencies during building = You have to reemerge KDE probably twice for some depedencies to built into packages. Probably some form of documentation about these depedencies may by aquired from KDE. Probably there is some way to generate ebuild depedencies and USE flags from this specification, so you don't have to do it manually.
I would say we need to set milestone on this onto 4.3 And we should double check for all automagic and version pulling. (and it is not minor but major problem)
Points 3 and 4 are not really valid. KDE4 build system does not build every application independently (like we do here) - instead - it builds modules whole (kdebase-runtime, kdenetwork etc). It results with the fact that some library detection code is put in common location - in toplevel CMakeLists.txt (instead of application subdirectory). So if you enable building of one application from modyle - it will still execute that common detection code - giving you misleading information that *this* particular application actually checks for it - which is just dummy check (that we need to hack around sometimes when it's put as REQUIRED).
Hi, so what happens, when this "dummy check" says, that certain component is not present? Is support for that component excluded from compilation? So when I add (emerge) that component, it is not plugged in automatically? Strazhce
Nope, read carefullt my previous post. As I said - such messages may be irrelevant to that particular package. For example we have: kdebase.tar.bz2 provides CMakeLists.txt that is utilized to build dolphin. konqueror, libkonq etc. In short, when we build libkonq, we comment out all in CMakeLists.txt all subdirectories except libs/konq. But some checks are relevant only to packages that really make use of them. For example soprano/nepomuk checks are run for every package from kdebase, but are relevant (used) only for dolphin and maybe some other - yet they may appear in cmake output for libkonq, konqueror etc. (in above example it may not be like it is actually, but you get the idea)
So if you just install some dependency listed there and not by changing any USE flags - *nothing* should change for that package (it's a bug if it's otherwise) And summarizing - any required dependencies should be hard dependencies, and optional should be exported as USE flags - and we try to keep it that way. If it's not the case for some particular package then of course it's a bug, and please fill a bug for that package if you spot one. But of course you need to know that feature XXX is really optional dependency of package YYY. - for ebuilds with 'inherit kde4-base', it's sufficient to read cmake output - for ebuilds with 'inherit kde4-meta', you need to know whether some dependency is wrong, usually by reading CMakeLists.txt files - not just by reading cmake output unfortunately I'm closing this one
Ah, if your bug with kopete and otr is still valid - please either reopen this bug *AND* rename Summary accordingly or open new bug for it.
