Apologies to the rest of you, Nigel and I have kind of taken over this bug, I think *is* relevant to the bug, so I'm continuing the discussion here.
Hi Nigel (2010.09.13_02:53:42_+0200) > I understand that general reasoning, but when we're still seeing > significant Linux traffic for Cg 2.0 --- it means that many many > users are effectively unsupportable by both Nvidia and Debian. That is true. As a non-free package Debian can offer little support (and makes this clear in README.Debian) > There are lots of known and resolved bugs in Cg 2.0, it's obsolete. I don't know how the release team usually handles binary-only packages, with regards to freeze exceptions (squeeze is frozen) and stable-proposed-updates (the way we get bugfixes to users). Such things are normally reviewed by looking at the size and complexity of diffs. Maybe someone who knows could tell you. If the current maintainers aren't being proactive enough about these things, (it's probably because they are too busy with other packages), I suggest you involve you prod them or get involved yourself. > I'll look into backports, but from a support perspective it > seems more complicated and costly than handing out the current > .deb, as we've just stared doing. Yes, however Linux distribution users are more likely to install things from their distro repositories than random websites. Something from your distro is probably less likely to break your system and is probably easier to get working. Plus you get updates without having to worry. This is an important concern, re security. Wearing my Debian User hat, I'm always very skeptical of commercial APT repositories / debs. I use the occasional bit of proprietary software, but I prefer to get it via a repository I trust. > It does seem a bit of a double standard that security updates > for open source can be cherry-picked into the mainline, whereas > closed source with security updates (and new features) can't > go out to real-world users. They (probably, I'm no expert on Debian non-free) can, someone just needs to make it happen. In the absence of diffs, changelogs will have to suffice. New features are usually not desirable for security updates, but non-free doesn't come with support, so we can take more risks. If the only way to get a security update is to get new features too, so be it. (Ubuntu now takes this approach with Firefox.) As to Ubuntu, are you aware of Canonical's partner repository [1]? Canonical allows third parties to get their proprietary applications included in the partner repository. I don't know how much of this is your own personal initiative and how much is Nvidia's desire to reach out to Linux users, but that is another possible option. [1]: http://www.canonical.com/engineering-services/certification/application-packaging > Our build directly packages .tgz, .rpm or .deb for Linux. > It was necessary to patch dpkg-deb to make this work > without fakeroot on RedHat. We specifically want to ship > the same binaries for _all_ Linux distributions, rather than > worry about bugs that could be per-distribution, due to a compiler > bug, or whatever. Thanks for that clarification. That means that it doesn't really make any difference whether we build from debs or tarballs, it's the same binary objects, just rearranged differently. > 271 warnings regarding "windows-devel-file-in-package" (MS DevStudio projects) Yeah, I thought those weren't relevant for Debian, so I removed them (the DirectX stuff too). > 414 warnings regarding "manpage-in-wrong-directory" (manCg, manCgFX, etc) Debian Policy 12.1. I moved them into man3, with named 3Cg etc. > 9 warnings regarding "image-file-in-usr-lib" (image files for examples) Examples should really go in /usr/share/doc/$package/examples. > Looking into the implications of versioned soname is on my to-do list.... That definitely requires package splitting, but would probably make your users (people who distribute Cg-linked applications) lives a little easier. > I guess it's "all good" in the sense that these new packages are being > consistent with the existing Debian ones, and we can be confident of > these being upgradable to the Nvidia ones. But, I'll check and > keep an eye on things, anyway. Thanks. >> Can it handle a user upgrading to it from the current Debian version? > > Yes, the idea is if/when Debian/etc is lagging, our package will always be > installable. I meant technically. I had to add a call to get nvidia-cg-toolkit-installer to remove any existing non-package-maintained-stuff in preinst. > But, I have limited discretionary cycles... Yeah, so do we all :/ (I should really spend more cycles on working on my MSc...) It's great to actually see someone from a commercial player like Nvidia engaging with Community distributions, I hope we can do something that works well for everyone. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
