1 |
On Fri, 23 Dec 2005 20:13:45 +0000, Stuart Herbert wrote: |
2 |
|
3 |
> Hi Peter, |
4 |
> |
5 |
> On Fri, 2005-12-23 at 14:05 -0500, Peter wrote: |
6 |
>> in any case. By unifying the ebuilds, we are merely duplicating what |
7 |
>> nvidia provides in its install packages. We're not doing anything they |
8 |
>> aren't. |
9 |
> |
10 |
> Who is "we" please? |
11 |
augustus, spyderous, azarah, me and testers. |
12 |
|
13 |
> As you're a non-dev, it would be polite to |
14 |
> introduce yourself at the top of emails like this for the benefit of |
15 |
> those who don't want to wade through that bug. You probably didn't |
16 |
> intend it this way, but your lack of introduction has distracted from |
17 |
> the work you're trying to do here. |
18 |
|
19 |
I was just doing as I was asked. Post an invitation for testing and |
20 |
comments. I did not think I had to do anything more other than document |
21 |
what this project is about. As for my lack of etiquette, I apologize. |
22 |
|
23 |
I'm peter, a user. I contribute ebuilds. Rox primarily, avfs, nvidia, |
24 |
libtrash, fuse, python-alsa plus I've commented on many more |
25 |
(enlightenment, eterm, etc,). I also rewrote the rox.eclass. In |
26 |
addition, I have made small contributions to several OS projects over the |
27 |
last seven years. I enjoy participating. |
28 |
|
29 |
This particular project _was_ my idea. I posted the bug with a first stab at |
30 |
the unified ebuild. augustus took it up and is now in charge. I truly felt |
31 |
there were two problems that this corrected. |
32 |
|
33 |
1) the existing ebuild code was a bit messy and outdated. Unifying the |
34 |
ebuilds forced a cleanup long overdue |
35 |
2) the concept of splitting a product seemed overly complex and |
36 |
unnecessary. |
37 |
|
38 |
The whole purpose of opening a bug on it was to have the concept reviewed, |
39 |
improved, or disregarded. |
40 |
|
41 |
I did _not_ do this project in order to defend it or try and justify it. |
42 |
If it fills a need, then it will be ported. If not, it won't. But just |
43 |
because something has always been done a certain way does not mean that |
44 |
it is the right way or it can't change. The ati drivers come as one |
45 |
package so why can't nvidia. The "extra" package ati has are far larger |
46 |
and far more complex than the TWO nvidia extra programs. The idea of |
47 |
having an nvidia kernel ebuild and a separate nvidia glx ebuild is not |
48 |
logical. glx depends on kernel, but not the other way around? Good luck |
49 |
running a glx app withing it! nvidia-settings and xconfig are so small |
50 |
they are insignificant in terms of compile time. 1' 10". |
51 |
|
52 |
And, consider from the user's pov. Wouldn't it be simpler and easier to |
53 |
say "emerge nvidia-drivers" and be done with it? |
54 |
|
55 |
So, that's it. Sorry for the non-intro, but I wasn't asked to do that. |
56 |
|
57 |
|
58 |
-- |
59 |
gentoo-dev@g.o mailing list |