1 |
On 12/24/05, Peter <pete4abw@×××××××.net> wrote: |
2 |
> On Sat, 24 Dec 2005 13:09:36 +0100, Carsten Lohrke wrote: |
3 |
> |
4 |
> > On Saturday 24 December 2005 12:34, Peter wrote: |
5 |
> >> THAT is a very reasonable comment! |
6 |
> > |
7 |
> > Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as |
8 |
> > we have to wait for proper sets and only to be used for a larger set of |
9 |
> > packages. Wrapping three or four ebuilds with another one, just for the sake |
10 |
> > of lazy people having only to emerge a single ebuild is ridiculous. The only |
11 |
> > valid point in the original idea to merge the nvidia-* packages is to reduce |
12 |
> > the overall number of packages in the repository. As you heard the voices |
13 |
> > against it, ranging from none to valid reasons, everything left is to bury |
14 |
> > the idea and to close the bug. |
15 |
> > |
16 |
> > |
17 |
> > Carsten |
18 |
> |
19 |
<snip> |
20 |
> |
21 |
> Also, I find it absolutely fascinating that the only people against this |
22 |
> concept are devs, and the only people for it are users. Remember that |
23 |
> users are your customers. Every effort should be made to keep them happy. |
24 |
> |
25 |
This is a voluntary based distro. Gentoo devs are users too only with |
26 |
added responsability (there's more to it but just for the sake of |
27 |
simplicity ...). I cannot speak for the maintenance side of things |
28 |
though. |
29 |
|
30 |
> If you are against meta ebuilds, what is your opinion on KDE? Instead on 9 |
31 |
> (or so) packages, there are now over 250! Are 250 separate ebuilds better? |
32 |
> I cannot think of another distro that slices up KDE that way. Meta |
33 |
> ebuilds at least allow the user the ability to opt out of trying to |
34 |
> decide which ebuilds to emerge! |
35 |
> |
36 |
Please check this url : http://packages.debian.org/stable/kde/. |
37 |
Actually, Gentoo was one of the very rare distro that was bundling |
38 |
kde-base, kde-network etc all in one big package. |
39 |
|
40 |
> I always used to use CVS to update my KDE source tree, then compile only |
41 |
> the changed modules. I could have a whole updated KDE inside an hour. Now |
42 |
> that is performance! |
43 |
> |
44 |
That is the whole point of the split kde ebuilds. It should be even |
45 |
faster than your method when conf-cache is fully implemented. I don't |
46 |
remember if it is finished though. It is also automated, less error |
47 |
prone and intergrated in our favorite package manager. Thank you KDE |
48 |
team for the good work by the way. |
49 |
|
50 |
> Here, with the unified nvidia, the intent was to REDUCE ebuilds and |
51 |
> simplify installation process. I thought the recommendation of a meta |
52 |
> nvidia ebuild is a worthy one worth consideration. |
53 |
> |
54 |
It simplifies the installation so to speak but for many gentoo users |
55 |
that changes their kernel often it's a pain. How would your ebuild |
56 |
react to module-rebuild ? |
57 |
|
58 |
> IMHO sometimes the desire to fine tune things and optimize things goes a |
59 |
> little over the edge. nVidia upstream combines all the products together |
60 |
> in their .run files. There is minimal time difference between having the |
61 |
> entire suite installed versus each one individually. And, from a user's |
62 |
> point of view, what could be simpler? |
63 |
> |
64 |
I agree with this but from a user point of view having both would be |
65 |
better. A meta ebuild with correct use flags that pulls the necessary |
66 |
dependency but leaves us with the flexibilty of easy kernel mangling |
67 |
is good even if it's a "a provisional and fugly workaround" when it's |
68 |
all we have for this type of situation. Albeit, when you remove the |
69 |
meta ebuild it doesn't remove it's dependency except if you run the |
70 |
very scary depclean and for good reasons. The user would be left with |
71 |
all the modules lying around when he though that it was removed. |
72 |
|
73 |
> Anyway, I appreciate your feedback. |
74 |
> |
75 |
Sure no problem. As a long time Gentoo user, I chose this distro for |
76 |
it's flexibilty and modularity not it's simplicity. Gentoo devs have a |
77 |
habit (policy ?) of following upstream as long as it fits well with |
78 |
the distro. Moreover, bugzilla is not used for discussing proposals. |
79 |
|
80 |
wkr and happy holidays |
81 |
|
82 |
Jean-Francois |
83 |
> -- |
84 |
> gentoo-dev@g.o mailing list |
85 |
> |
86 |
> |
87 |
|
88 |
-- |
89 |
gentoo-dev@g.o mailing list |