On 12/24/05, Peter <[EMAIL PROTECTED]> 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 > <snip> > > 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
