Here's a set of patches to clean up dependencies for kde 3.3 Infos taken a bit fro http://www.kde.org/info/requirements/3.3.php and mainly looking at the source. * kdelibs - media-libs/tiff should be protected by the 'tiff' use flag (listed as optional in requirement list and autodetected) however there's no configure switch for it, so there are also reasons to not make it optional. - python: it is not checked in configure and it is listed only for kdebindings and koffice in requirements list. Safe to remove? (It is in system profile anyway) - add sys-apps/utempter (bug 18252) * kdebase - cdparanoia and lame dependencies moved from kdebase to kdemiltimedia, so they are not needed here (and are in kdemultimedia already). - the motif dependency is gone (*wheee*): http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/nsplugins/viewer/nsplugin.cpp the patch is in HEAD, not in beta2, so it will be effective in beta3/rc1. - kde uses a lot of features from libsmbclient, so the dep on samba should restrict to samba >= 3 - the freetype dep is not needed (already dep of qt) * kdepim - ldap support comes from kdelibs/kdebase, so the openldap dep is unneeded. - in 3.2 the support for encrypted mails came from gnupg and from the the crypt plugin for gpgme-0.3.x (app-crypt/cryptplug). in 3.3 the crypto support is done entirely linking to gpgme 0.4.x, with gnupg as a fallback alternative. These infos are partially here: http://cvs-digest.org/?issue=jan92004 and in configure.in. don't know how to deal with the case USE="-crypt", though, since in that case kdepim still enables gpgme support linking to kdepim/libkdenetwork/gpgme-copy. - no need to specify extra-includes=/usr/include/libpisock, it's autodetected. - in kdepim there's a 'libkdenetwork' subdir, so I don't think the dep on kdenetwork is needed. - dodoc *.html does nothing. * kdemultimedia - the gstreamer dep is useless, since it does not work without the gstreamer kde bindings (bug 43417, bug 40547) - add conditional speex dep - make xine dep conditional see the attached patch for reference, take a look at it when preparing the next release of kde, thanks!
Created attachment 36312 [details, diff] kde3.3-deps.patch reference patch for the above changes
ok, i've implemented some of these in the beta2 ebuilds now so we get some testing done on them. i've bumped kdepim to a new version, the rest stayed the same. going to leave this open until we get all of them resolved.
Caleb, just a quick note on kdepim-3.3.0_beta2-r1.ebuild: gpgme should forced to a version >=0.4.5, otherwise the configure check will fail, and GPGME_CONFIG should be set in src_compile() to let kdepim find the right version (0.4 and not 0.3) (see the patch) I also thought whether the dep should be 'gpgme' or '|| (gpgme, gnupg)'. Since gpgme is used in any case (either statically from a private copy or linking the installed one), it makes sense to force gpgme in all cases, and one could even make gpgme a non-conditional dep (removing the crypt use flag). Stricly speaking, it is not 'bloat' as removing the dep on gpgme causes the increase of the size of the kdepim binaries of the amount of the static library. So my suggestion is DEPEND="... >=app-crypt/gpgme-0.4.5" without the crypt use flag. also, from configure.in: "You are missing gpgme 0.4.5 or higher." "Gpgme will be built statically from libkdenetwork/libgpgme-copy." "If you are a packager, we most strongly recommend to build against" "the system's shared gpgme." "Consider downloading gpgme >= 0.4.5 from ftp://ftp.gnupg.org/gcrypt/alpha/gpgme" "or use the --with-gpgme-prefix=/path/where/gpgme/is/installed option."
Also I have read the latest gnupg is required 1.9.x or the newly released stable 1.2.5.
Don't know precisely... gnupg should come as a dependency of gpgme, and from what I gathered the gpgme ebuild should depend on >=gnupg-1.9 if support for s/mime is requested, or on >=gnupg-1.2 if s/mime is not requested. At the moment the gpgme ebuild does not do that though, I wrote in bug 50681 because of this. Also, in kdepim/configure.in there's NEED_GPG_VERSION=1.2.2 NEED_GPGSM_VERSION=1.9.3 but I don't know what the effect is.
GpgMe won't build with gnupg support if you don't: ln -s /usr/bin/gpg2 /usr/bin/gpg after you install >=gnupg-1.9 which results in Kmail not working correctly with some security features. I know this isn't directly related to this bug but it will cause some problems for trying to get this working. bug 56937 mentions this.
Another thing I just found. checking for gpgme-config... /usr/bin/gpgme-config checking for GPGME - version >= 0.4.5... no, will use local libgpgme-copy gpgme >= 0.4.5 doesn't install gpg-config, it installs gpg4-config. My gpg-config version here is 0.3.14 and gpg4-config version is 0.4.7, I'm not sure if this affects the build in anyway. Also gpgme-0.9.0 has been released but isn't in portage yet.
A lot of infos here: http://bugs.kde.org/show_bug.cgi?id=85009 and here: http://bugs.kde.org/show_bug.cgi?id=83086 so, gnupg should be >= 1.2.5 to avoid a grave bug (thus dep should go in the gpgme ebuild, I think)
I've added an ebuild for gpgme-0.9.0 - a copy of 0.4.7 (masked as "-*"). I changed the dep requirement to >=gnupg-1.2.2 (as listed in the package). I added "--with-gpg=/usr/bin/gpg2" so it finds gpg2 if it exists (per comment #6). There seems to be a bug in gpgme-0.9.0 that only looks for the hardcoded "gpg" binary in the mkdemodirs script - it will either need to be "sed'd" or get fixed upstream. I tried filing a bug report upstream but the web site just spit out http errors when i clicked "Submit" I've put in a request with the developer in charge of gnupg to lift the package mask so that we can have gpgme and gnupg install properly, and I can then set it as a kdepim dependency. If someone can put in a bug-request for gnupg-1.2.5 that may be helpful too.
Modified kdepim-3.3.0_beta2-r1.ebuild to reflect these latest changes. Will probably push out an -r2 if we get the gnupg/gpgme things fixed before the next kde version rolls out.
kdelibs_rc1 now has tiff package use flagged also, removed the runtime python dependency kdebase_rc1 has motif dep removed
added a local cdparanoia use flag since it's listed as optional
changed multimedia-3.3.0_rc1 to: oggvorbis? ( media-sound/vorbis-tools ) as the tools are required for some functionality, and that pulls in the necessary libogg and libvorbis deps.
Thanks for your work Caleb! Final quirks: in kdebase remove `use_with motif` and `use_with encode lame` in kdemultimedia add "use xine || DO_NOT_COMPILE="$DO_NOT_COMPILE xine_artsplugin" somewhere and "`use_with cdparanoia`", too. and there's something new: in rc1 the dependency on trm (and musicbrainz), needed for tagging support in juk, has been changed to libtunepimp (and musicbrainz) ( http://www.musicbrainz.org/products/tunepimp/ ) see here: http://cvs-digest.org/index.php?comment&diff&comment&file=kdemultimedia/juk/trackpickerdialogbase.ui,v&comment&version=1.5
Removed trm dep from kdemultimedia. Will have to look at libtunepimp dep a little later. I noticed this when compiling kdepim: libgnokii (http://www.gnokii.org) is missing. The KDE Addressbook mobile phone import/export filter will not be available. You're missing the pisock library for kpilot. KPILOT: MAL headers or library not found. AvantGo conduit will not be compiled. KPILOT: Download libmal>=0.20 from http://jasonday.home.att.net/code/libmal/ So it looks like we may need some more deps here as well.
Just added tunepimp library -> media-libs/tunepimp This will need to become an (optional) dep of kdemultimedia; needs some more testing first though.
Thanks for adding tunepimp, a quick review: license should be GPL-2; there should be a block on "media-sound/trm", and media-sound/trm should block media-libs/tunepimp (they both provide /usr/bin/trm); dependency on musicbrainz should be forced to >=2.1.0; and description and homepage should be something like that: DESCRIPTION="Client library to create MusicBrainz enabled tagging applications." HOMEPAGE="http://www.musicbrainz.org/products/tunepimp/"
I have another missing kdebase dependency for you, Caleb. ksysguardd depends on lm-sensors, a version bump to libsensors.so.X+1 gives a "Connection to localhost has been lost!" message when opening ksysguard, because ksysguardd segfaults then. workaround: symlink so.X+1 so.X
Caleb, thanks a bunch for the great things you are doing for KDE/Gentoo. Just want to let you know that krfb (kdenetwork) now depends on a patched version of rdesktop for remote control of rdp-clients. See http://bugs.gentoo.org/show_bug.cgi?id=58312 for more information.
I think this change below will allow all ebuilds using the kde.eclass to now support --with(out)-arts, EXCEPT the 3.2 version of kde itself. -# $Header: /var/cvsroot/gentoo-x86/eclass/kde.eclass,v 1.101 2004/07/27 15:52:25 caleb Exp $ +# $Header: /var/cvsroot/gentoo-x86/eclass/kde.eclass,v 1.102 2004/08/18 18:07:14 caleb Exp $ # # Author Dan Armak <danarmak@gentoo.org> # @@ -88,7 +88,7 @@ kde_src_compile() { else myconf="$myconf --disable-debug --without-debug" fi - [ "$KDEMINORVER" -ge 3 ] && myconf="$myconf `use_with arts`" + [ "$KDEMINORVER" -ne 2 ] && myconf="$myconf `use_with arts`"
kde.eclass fix for arts: - [ "$KDEMINORVER" -ne 2 ] && myconf="$myconf `use_with arts`" + [ -z "$KDEBASE" ] && myconf="$myconf $(use_with arts)" + [ -n "$KDEBASE" -a "$KDEMINORVER" -ge 3 ] && myconf="$myconf $(use_with arts)"
Created attachment 38257 [details, diff] Proposed patch to allow optional jack compilation as a dep This patch allows one to use --disable-jack to turn off jack checking in arts. Please comment, as I plan to submit it upstream.
Added this patch to portage, with the optional jack use flag.
I think everything here was taken into account. Closing.