Hi Nigel (2010.09.12_19:01:47_+0200) > From an Nvidia point of view we're mainly concerned about having > the most current release in circulation, and making it easy > to deploy Cg either via the normal packaging channel, or directly > from Nvidia, as necessary.
I'm sure most upstreams feel that way, however the Linux distribution's job is do integration work and produce a cohesive, stable release. That means we can't simply distribute the latest version of everything. And practically speaking, most users don't need the latest versions, they need versions that work and are well supported. That's why they chose Debian. If your users get this package via Debian, they are getting the version that the Debian maintainer of the package has provided. If you want to provide newer releases for your users, you can use the backports process that both Debian [1] and Ubuntu [2] have. If you want to do that outside the control of Debian/Ubuntu, you could provide your own APT repository (or Launchpad PPA [3]), however many users would probably stick to the distribution-provided versions. [1]: http://backports.debian.org/Contribute/ [2]: https://help.ubuntu.com/community/UbuntuBackports [3]: https://wiki.ubuntu.com/Upstream > My main concern would be with incompatibilities or inconsistencies in > the Nvidia-packaged .debs and the Debian/Ubuntu-packaged .debs, > resulting in end-user issues and forum/blog ranting. Yes, it would be best to minimise those. This package is a bit of a special case in that it's proprietary, binary-only software, so while you can build it on contemporary Debian and Ubuntu machines, we are stuck with whatever binaries you provide. 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. > Would it be possible for the packages to build based on the Nvidia > .deb packages, rather than the tgz? Technically, yes. However Debian source packages are built from a (*source*) tarball. The tarball could contain your two debs, but you had two convenient tarballs, so I used them instead. They are a much better fit with the Debian workflow (even if they are proprietary and binary). 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 (My package still lists 22 issues, but they are upstream issues, out of my control) Can it handle a user upgrading to it from the current Debian version? There are other issues, like the addition of manpage sections. > it would be a shame for there to be a duplication of that effort, and > inconsistent interpretations of the packaging policy. That's something for you to coordinate with the Debian Package maintainer rather than me. If you are interested in co-maintaining the package with him, ask him. Having an active upstream developer who wants to help can make Debian package maintenance much easier. > So having different packages due to "infrastructure requirements" > seems a bit unfortunate from that point of view. Debian's infrastructure assumes that we are dealing with free software. The build system and best practices are designed to ensure that we meet the Debian Free Software Guidelines [4]. Obviously it can be bent to build from anything we can shove inside a tarball, as I described above, but the packages that are the easiest to work with are those that stick to the conventions. [4]: http://www.debian.org/social_contract > I guess the best I can do it ensure that the Debian/Ubuntu and Nvidia > packaged debs remain as interchangeable as possible. 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. > We're open to splitting the packages into -lib, -dev and -doc > components, but have not prioritized that work internally, yet. Considering the package only has two reverse dependencies and is only built for two architectures, this isn't a particularly urgent job. > We do have some inertia about keeping things simple and > consistent with the way we package for other platforms. And we have inertia about keeping things simple and consistent with the way we deal with other packages :) > One nice thing would be the possibility of installing both > 32-bit and 64-bit binaries on a 64-bit machine, which currently > is prevented by the documentation and headers conflicting. Debian/Ubuntu doesn't support multi-arch yet. But its coming some time soon... > Aside from that, if there is some way we can help push (backport?) > Cg 3.0 into Ubuntu 9.04, 9.10 and 10.4, (and Debian maintenance) > that's something else we'd like to see. Yes, see [1], [2]. > Best wishes for 10.10! Thanks. And I'm hoping for a speedy squeeze release too. SR BTW: Your filename version number scheme is not particularly amenable to machine comparison. 3.0.0007 is way preferable to 3.0_July2010. -- 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
