On 30 October 2010 12:45, Stéphane Gaudreault <stephane@archlinux.org> wrote:
The main disadvantage of this solution is the addition of proprietary software for which we can only provide limited support in case of bugs or incompatibility with other updates.
This won't likely be an issue. It's a given that no one should be expecting much assistance from the distribution in the event a package is of a proprietary nature. When a problem arises, just don't hold back anything else, which brings us to...
According to the maintainer of the Cuda package in AUR [4], Cuda requires gcc version 4.4 (it is broken with version 4.5) and sometimes releases depend on beta drivers[5]. I think it is probably better to wait until these dependency problems are fixed before thinking about inclusion in [extra] or [community].
Wait or don't wait, this has no long-term guarantee. It can break anytime. [extra] is definitely not a good place for it. The fact that random releases may depend on beta drivers convinces me to leave it in [unsupported], unless those drivers are brought in as well.
My suggestion would be to package only OpenCL headers (Khronos version) and eventually discuss addition of Cuda if it becomes easier to maintain in a rolling release distribution.
Yes, do that.
The new "khronos-opencl-headers" package could be added as optional dependencies for nvidia-utils which will also include a "provides=('libCL')"[6]. I tested this solution on several codes and it works well. It also seems that Debian is going to do something very similar[7].
Same here, I think a straightforward name would suffice. Also, it's unnecessary to have it as any kind of dependency.