Stefano,
> That means we can't simply distribute the latest
> version of everything.
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.
There are lots of known and resolved bugs in Cg 2.0, it's obsolete.
So Nvidia could go the backports way, or simply recommend that they
install the .deb packages directly from the Cg download page.
http://developer.nvidia.com/object/cg_download.html
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.
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.
Most users don't need the latest versions
They do if they need/want security related patches.
I don't know what your build process is, but if you could use the same
source packages Debian uses (it looks like your version is a fork of
Debian's) then you should be able to achieve this.
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.
> I did look at your deb, but it didn't look like it obeyed Debian Policy
> of the FHS very well, so I based by installation layout on the current
> Debian package instead.
We've gone to some trouble to be lintian clean,
Is it really lintian clean?
$ lintian Cg-3.0_July2010_x86.deb | wc -l
702
$ lintian --version
Lintian v2.3.4ubuntu2
271 warnings regarding "windows-devel-file-in-package" (MS DevStudio projects)
414 warnings regarding "manpage-in-wrong-directory" (manCg, manCgFX, etc)
9 warnings regarding "image-file-in-usr-lib" (image files for examples)
...stemming from Cg being intended as an SDK....
(So I take these with a grain of salt)
W: nvidia-cg-toolkit: package-name-doesnt-match-sonames libCg libCgGL
W: nvidia-cg-toolkit: new-package-should-close-itp-bug
W: nvidia-cg-toolkit: copyright-without-copyright-notice
W: nvidia-cg-toolkit: possible-unindented-list-in-extended-description
W: nvidia-cg-toolkit: extra-license-file
usr/lib/nvidia-cg-toolkit/examples/OpenGL/glew/LICENSE.txt
W: nvidia-cg-toolkit: maintainer-script-ignores-errors postinst
W: nvidia-cg-toolkit: shlib-without-versioned-soname usr/lib/libCg.so libCg.so
W: nvidia-cg-toolkit: shlib-without-versioned-soname usr/lib/libCgGL.so
libCgGL.so
Looking into the implications of versioned soname is on my to-do list....
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.
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.
Agreed. If you involve yourself in the Debian and Ubuntu maintenance of
these packages (community participation is always welcome), then you can
do this from both sides.
That is something to consider, certainly.
But, I have limited discretionary cycles...
BTW: Your filename version number scheme is not particularly amenable to
machine comparison. 3.0.0007 is way preferable to 3.0_July2010.
Tell me about it! :-)
- Nigel
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
