| 1 |
On Saturday 24 December 2005 16:31, Peter wrote: |
| 2 |
> Not really. glx does not compile at all and the entire pkg file has to be |
| 3 |
> extracted. Same amount of files being processed... |
| 4 |
No, because the glx part files needs to be processed by portage, too, and |
| 5 |
that's something that takes time, especially now that portage uses paxutils |
| 6 |
to find texrels and company. |
| 7 |
|
| 8 |
> FBSD is a problem already. It's not even a valid arch at the moment |
| 9 |
I'm working on it, the problem is that we had to get rid of x86-fbsd keyword |
| 10 |
in arch.list to avoid devs wasting time from running repoman for x86-fbsd |
| 11 |
profiles. |
| 12 |
An alternative is to check CHOST. |
| 13 |
|
| 14 |
>Anything current with fbsd is at the best a |
| 15 |
> complete hack. |
| 16 |
In GLX? I don't really think so, a part a couple of special cases, the most of |
| 17 |
the ebuild works in the same manner for both of them, there are name changes |
| 18 |
due to the different versions. |
| 19 |
And for the kernel module, it's _completely_ different, that's why I don't |
| 20 |
want the Linux module and the FreeBSD module to be in the same ebuild. I have |
| 21 |
an nvidia-freebsd package on gentoo/alt overlay. |
| 22 |
|
| 23 |
> Then, there is one last issue you did not consider. If nvidia releases a |
| 24 |
> new driver, there is no dependency from kernel -> glx. |
| 25 |
This would make it a circular dep, I would say to poke portage devs about |
| 26 |
that. |
| 27 |
|
| 28 |
-- |
| 29 |
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ |
| 30 |
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE |
Archives