> Questions:
>
> * You have prepared the /usr/lib32/mesa directory. Will the
> ia32-libs as well become support for alternatives. Yet the the
> GL libraries are located in /usr/lib32/libGL.so.1.2
>
>
Hi Rafael.
That library is installed by the ia32-libs package, which I haven't modified
yet. Currently that package doesn't contain an updated version of mesa,
therefore it won't work anyway (yet). This problem was already on my radar
;)
I'll fix it.
> * Installing the nvidia-current-dev requires the removal of
> libgl1-mesa-dev. I don't see the reason why that should be.
> Specially since a growing hardware base has hybrid graphics
> where one only have to switch between the desired gpu solutions,
> this is a little contra against the option to install everything
> without your package and be free to use any beta, actual on a
> Daily basis.
>
>
Good point. They are just development headers (i.e. most users shouldn't
care about them) but this conflict wasn't intended. Thanks for bringing this
to my attention.
--
Alberto Milone
Sustaining Engineer (system)
Foundations Team
Canonical OEM Services
2010/1/11 Raphael Gradenwitz <email address hidden>
> Questions: libGL.so. 1.2
>
> * You have prepared the /usr/lib32/mesa directory. Will the
> ia32-libs as well become support for alternatives. Yet the the
> GL libraries are located in /usr/lib32/
>
>
Hi Rafael.
That library is installed by the ia32-libs package, which I haven't modified
yet. Currently that package doesn't contain an updated version of mesa,
therefore it won't work anyway (yet). This problem was already on my radar
;)
I'll fix it.
> * Installing the nvidia-current-dev requires the removal of
> libgl1-mesa-dev. I don't see the reason why that should be.
> Specially since a growing hardware base has hybrid graphics
> where one only have to switch between the desired gpu solutions,
> this is a little contra against the option to install everything
> without your package and be free to use any beta, actual on a
> Daily basis.
>
>
Good point. They are just development headers (i.e. most users shouldn't
care about them) but this conflict wasn't intended. Thanks for bringing this
to my attention.
--
Alberto Milone
Sustaining Engineer (system)
Foundations Team
Canonical OEM Services