| 1 |
On Sat, 24 Dec 2005 14:09:01 +0100, Diego 'Flameeyes' Pettenò wrote: |
| 2 |
|
| 3 |
snip... |
| 4 |
>> nVidia upstream combines all the products together |
| 5 |
>> in their .run files. There is minimal time difference between having the |
| 6 |
>> entire suite installed versus each one individually. |
| 7 |
> Well depends how you see it. |
| 8 |
> If you just build it when you update the drivers, yeah there's a minimal |
| 9 |
> difference. |
| 10 |
> But if you have more than one kernel (for whatever reason), and you want to |
| 11 |
> have the latest kernel on all of them, it's way faster to just use |
| 12 |
> nvidia-kernel. |
| 13 |
|
| 14 |
Not really. glx does not compile at all and the entire pkg file has to be |
| 15 |
extracted. Same amount of files being processed... |
| 16 |
|
| 17 |
> |
| 18 |
> Then there's the point I've already said, about mixing the kernel-level |
| 19 |
> with generic userland stuff: for Gentoo/FreeBSD I need it to be split, |
| 20 |
> or I'd have to recreate a copy ebuild especially for FBSD... and that |
| 21 |
> not only sucks from an user POV but also from a maintenance POV. |
| 22 |
|
| 23 |
FBSD is a problem already. It's not even a valid arch at the moment |
| 24 |
(x86-fbsd). Work is ongoing to pull in the required sources: |
| 25 |
ftp://download.nvidia.com/freebsd/1.0-8178/NVIDIA-FreeBSD-x86-1.0.8178.tar.gz |
| 26 |
and get it integrated. Anything current with fbsd is at the best a |
| 27 |
complete hack. |
| 28 |
|
| 29 |
The making of those sources differs substantially from current. Perhaps |
| 30 |
you could help evaluate it? |
| 31 |
|
| 32 |
Then, there is one last issue you did not consider. If nvidia releases a |
| 33 |
new driver, there is no dependency from kernel -> glx. It's possible that |
| 34 |
a user could update kernel, and NOT glx. That would be bad. Here, |
| 35 |
everything will be kept in sync guaranteed. |
| 36 |
|
| 37 |
-- |
| 38 |
gentoo-dev@g.o mailing list |
Archives