On Saturday 24 December 2005 13:50, Peter wrote: > Would you please add the comments to the bug report? Or, may I copy them? > Please advise.
Feel free to do so. > 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. The only valid issue I read about against a single nvidia-driver package was Diego's regarding FreeBSD. On the other hand having packages split or merged only because it can be done, doesn't make much sense. Regarding happiness, merry x-mas and best wishes to everyone, but I care about maintainability in the first place. You may be interested in GLEP 21¹, a very user friendly approach to easily group user defined packages. > 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! The split was due and having meta packages of some sort was necessary due to the amount of packages. The problems are present though: re-emerging and un-emerging meta packages doesn't affect their child packages. For reasons why the split ebuilds are an advantage please refer to The KDE Split Ebuilds HOWTO². The big downside of (the large number of) split packages is the affect on the code base of the stable Portage versions (and the current layout of the repository), which apparently is not created having scalability issues in mind. > 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! But this has nothing to do with providing a large user base with a reasonable stable set of packages. > 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. As explained above, it isn't. > 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? > > Anyway, I appreciate your feedback. If Diego could explain what the FreeBSD problem is and if he can resolve it, personally I don't see a valid reason against having a unified nvidia-driver package. I assume all the steps Portage is doing to install those packages (and uninstall previous versions) will take more time than having it bundled in a single ebuild, anyways. But raising the number of packages by a crappy meta ebuild (sorry, lazy users don't count) - no. Carsten [1] http://www.gentoo.org/proj/en/glep/glep-0021.html [2] http://www.gentoo.org/doc/en/kde-split-ebuilds.xml#doc_chap3
pgpjar6Psrvfo.pgp
Description: PGP signature
