From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EqAts-0000Zt-JM for garchives@archives.gentoo.org; Sat, 24 Dec 2005 15:01:37 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBOF039S008139; Sat, 24 Dec 2005 15:00:03 GMT Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBOEvdGm001069 for ; Sat, 24 Dec 2005 14:57:39 GMT Received: by zproxy.gmail.com with SMTP id z31so797210nzd for ; Sat, 24 Dec 2005 06:57:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cmlLGb3WQGQoCDVQbSeGxoJ+gNzNZ3Z6yfi5sasPFfgB6m5HLsyP/SktDQbr2qcaNms05/ndGehNzp15kKLUXEE7HLSkGZH6mnJx67FQPxA9gcZoJykT4Ec20eWVROaNU3oo2eu8u2zf3GE9hkjFJRMHgNW+nqri2047KTUhXkc= Received: by 10.65.204.4 with SMTP id g4mr119422qbq; Sat, 24 Dec 2005 06:57:38 -0800 (PST) Received: by 10.65.145.20 with HTTP; Sat, 24 Dec 2005 06:57:38 -0800 (PST) Message-ID: <4a64cf400512240657t6ec786b3ge207579f9805c6e2@mail.gmail.com> Date: Sat, 24 Dec 2005 09:57:38 -0500 From: Jean-Francois Gagnon Laporte To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: Re: Unified nVidia Driver Ebuild ready for testing In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <43AD1205.1050403@exceedtech.net> <200512241309.44268.carlo@gentoo.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id jBOEvdGm001069 X-Archives-Salt: 61359860-e64e-4630-917d-8ccab40004d3 X-Archives-Hash: 297c86f35d79ae596f800cd712f5d9b9 On 12/24/05, Peter wrote: > On Sat, 24 Dec 2005 13:09:36 +0100, Carsten Lohrke wrote: > > > On Saturday 24 December 2005 12:34, Peter wrote: > >> THAT is a very reasonable comment! > > > > Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as > > we have to wait for proper sets and only to be used for a larger set of > > packages. Wrapping three or four ebuilds with another one, just for the sake > > of lazy people having only to emerge a single ebuild is ridiculous. The only > > valid point in the original idea to merge the nvidia-* packages is to reduce > > the overall number of packages in the repository. As you heard the voices > > against it, ranging from none to valid reasons, everything left is to bury > > the idea and to close the bug. > > > > > > Carsten > > > Also, I find it absolutely fascinating that the only people against this > concept are devs, and the only people for it are users. Remember that > users are your customers. Every effort should be made to keep them happy. > This is a voluntary based distro. Gentoo devs are users too only with added responsability (there's more to it but just for the sake of simplicity ...). I cannot speak for the maintenance side of things though. > If you are against meta ebuilds, what is your opinion on KDE? Instead on 9 > (or so) packages, there are now over 250! Are 250 separate ebuilds better? > I cannot think of another distro that slices up KDE that way. Meta > ebuilds at least allow the user the ability to opt out of trying to > decide which ebuilds to emerge! > Please check this url : http://packages.debian.org/stable/kde/. Actually, Gentoo was one of the very rare distro that was bundling kde-base, kde-network etc all in one big package. > I always used to use CVS to update my KDE source tree, then compile only > the changed modules. I could have a whole updated KDE inside an hour. Now > that is performance! > That is the whole point of the split kde ebuilds. It should be even faster than your method when conf-cache is fully implemented. I don't remember if it is finished though. It is also automated, less error prone and intergrated in our favorite package manager. Thank you KDE team for the good work by the way. > Here, with the unified nvidia, the intent was to REDUCE ebuilds and > simplify installation process. I thought the recommendation of a meta > nvidia ebuild is a worthy one worth consideration. > It simplifies the installation so to speak but for many gentoo users that changes their kernel often it's a pain. How would your ebuild react to module-rebuild ? > IMHO sometimes the desire to fine tune things and optimize things goes a > little over the edge. nVidia upstream combines all the products together > in their .run files. There is minimal time difference between having the > entire suite installed versus each one individually. And, from a user's > point of view, what could be simpler? > I agree with this but from a user point of view having both would be better. A meta ebuild with correct use flags that pulls the necessary dependency but leaves us with the flexibilty of easy kernel mangling is good even if it's a "a provisional and fugly workaround" when it's all we have for this type of situation. Albeit, when you remove the meta ebuild it doesn't remove it's dependency except if you run the very scary depclean and for good reasons. The user would be left with all the modules lying around when he though that it was removed. > Anyway, I appreciate your feedback. > Sure no problem. As a long time Gentoo user, I chose this distro for it's flexibilty and modularity not it's simplicity. Gentoo devs have a habit (policy ?) of following upstream as long as it fits well with the distro. Moreover, bugzilla is not used for discussing proposals. wkr and happy holidays Jean-Francois > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list