From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21484 invoked from network); 19 Sep 2004 18:03:15 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 19 Sep 2004 18:03:15 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1C961y-0003mm-Lo for arch-gentoo-dev@lists.gentoo.org; Sun, 19 Sep 2004 18:03:22 +0000 Received: (qmail 27188 invoked by uid 89); 19 Sep 2004 18:03:14 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 25341 invoked from network); 19 Sep 2004 18:03:13 +0000 From: Simone Gotti To: gentoo-dev@lists.gentoo.org Date: Sun, 19 Sep 2004 20:08:23 +0200 User-Agent: KMail/1.7 References: <200409180057.34014.anthony@ectrolinux.com> <200409191030.34385.simone.gotti@email.it> <200409191748.28063.danarmak@gentoo.org> In-Reply-To: <200409191748.28063.danarmak@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409192008.23813.simone.gotti@email.it> X-Virus-Scanned: Cineca AppOs 0.81 at as2.cineca.it Subject: Re: [gentoo-dev] Segregating KDE? X-Archives-Salt: ef53e047-ac52-44a4-9677-d0a72284db8d X-Archives-Hash: 700840cacc477c6faca2037a56326e13 On Sunday 19 September 2004 16:48, Dan Armak wrote: > > The aren't badly written, this is the right behavior, For example kmail > > wants to compile against libkdepim. You can't link against a library that > > isn't already installed o an old installed one with less functions. > > Should be a fallback IMHO. configure can check for things like that. At > least, we're going to have to make it do that if we go through with this > :-) > As for old versions, isn't that what library versions are for? You're right. The real problem is that library version usually are the same in ALL kde 3.X. Because they must be Binary Compatible (B.C.) (this means of course al source compatible). In c++ you can mantain the B.C. also adding some new methods to a class, with the exception that this one doesn't have to be a virtual method. I've noticed that between every version of kde some libs ends with the same *.so.X.X also if they adds some new functions (I hope to be wrong...). By the way, I think that it's possible to split EVERY kde program/libs in a single package, this can be possibile by heavily patching the Makefiles like you've said so they can link to an installed lib instead of the local one, this libs will be a dep of the program and it should be of course a different ebuild. I'm already giving a little help to caleb and carlo on the kde ebuilds and if ypu and they think that a lot of people thinks that having single kde programs instead of the standard modules will be a better idea I'll be VERY happy to start hacking on this. My great fear is that it will slow down the development of the ebuilds because this bring to a lot of additional work! Think that probably the Makefile's patches must be changed on every kde major release. All I need is to know if you (gentoo kde developers) are really interested on this work. Let me know! Bye! -- Simone Gotti http://kde-bluetooth.sf.net -- gentoo-dev@gentoo.org mailing list