support multiarch: same

Status changed to 'Confirmed' because the bug affects multiple users.

As far I understand nvidia-cg-toolkit has native builds for 64 bits...

http://developer.nvidia.com/cg-toolkit

So, why we need implement multiarch support?

I don't see any benefit in using a 32-bit library if you can use a 64-bit library.

I'm a developper of PCSX2 which is a PS2 emulator. The emulator is a kind of virtual machine and work only for 32 bits. So it is not possible to link the 64 bits libcg*.so to it.

Anyway, multiarch does not cost anythings. The biggest issue here is the non-policy compliant package, if I'm correct library must be in separate binary package. Multiarch impacts less than 10 lines, I can provided a patch for it when the package will be properly split.

By the way, would you be correct to do that?
1/ move libcg.so into libcg package
2/ move libcggl.so into libcggl package
3/ make nvidia-cg-toolkit depends on both libcg and libcgg package

It would make this package multiarch compatible and avoid any impact on reverse dependency.

Ok I was on good mood today. Please find attached 2 patches.

The first one split the package, more exactly it create libcg and libcggl. Be aware of the conflict/provide/break stuff, I don't know what must be do to handle it properly. It might need some tuning.

The second effectly implement multiarch. Ie move library in /usr/lib/$(DEB_HOST_MULTIARH)

The 2nd patch.

The attachment "split-cg-lib-package.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Hi, thanks for this effort.

BTW, if you want to expose a bunch of discrete changes like this, the UDD (bzr) workflow can work nicely.

While you are here, can we update this to the latest CG toolkit version?

The description probably should say "In this package" rather than "the components include"

Why are we splitting libcg from libcggl? They are provided togother, and don't have a stable ABI (does they?). It's also starting to look like nvidia-cg-toolkit should be broken into libcg-dev and libcg-bin.

I don't think we need the preinst or postrm (debhelper should take care of that), but we do need that preinst in all the binary packages, or we could break the upgrade path from lucid.

There should be a build-depends on dpkg-dev (>= 1.16)

The conflicts should be on (<< 3.0.0007-0ubuntu2) obviously, increase that if you do a newer upstream version.

There should be a "set -e;" before the for loop.

Please include a descriptive changelog entry.

I suggest enganging with the Debian maintainer about this, as well. There were no responses to my "multi-orig rather than download during postinst" changes, but you never know, sometimes another poke is all that's needed...

BTW, I can't see any reverse dependencies. Although there is one reverse-build-dependency: crystalspace-glshader-cg

Hello Stefano,

>> BTW, if you want to expose a bunch of discrete changes like this, the UDD (bzr) workflow can work nicely.
I'm only a debian user and a developer of a 32bits application (PCSX2) so I don't know anything about the UDD workflow. If you can share me some input I will be glad.

>>BTW, if you want to expose a bunch of discrete changes like this, the UDD (bzr) workflow can work nicely.
Yes you can upgrade to latest cg if you want. My PCSX2 users only need the multiarch feature which will become more critical because Ubuntu advises people to use a 64 bits versions.

>>Why are we splitting libcg from libcggl? ....
I split them for no particular reason. I saw that control file provide libcg and libcggl so I create two packages. They can be merged. Maybe we can do a review of the package slit.
/usr/include/* -> libcg-dev
/usr/lib/* -> libcg
remaining (doc, bin) -> nvidia-cg-toolkit or rename the package if you want. Maybe we can split all doc into a libcg-doc (or nvidia-cg-toolkit-doc) but my packager skill is beginner.

>> I don't think we need the preinst or postrm (debhelper should take care of that), but we do need that preinst in
>> all the binary packages, or we could break the upgrade path from lucid.
I didn't understand anything on the prerm/postint stuff. What do you want to do exactly?

>> I suggest enganging with the Debian maintainer about this, as well
Nvidia-cg-toolkit seems abandoned on debian. It didn't get any update from a long time (latest was on 19 Mar 2009). Current version is deprecated by Nvidia which send a "please upgade message" to all bts bug report ! For information there is another reverse-dependency : ogre-plugins-cgprogrammanager (at least on debian)

Cheers,
Gregory

Hi gregory (2011.11.21_17:17:35_+0200)
> I'm only a debian user and a developer of a 32bits application (PCSX2)
> so I don't know anything about the UDD workflow. If you can share me
> some input I will be glad.

UDD is the bzr branches every package has.
http://developer.ubuntu.com/packaging/html/udd-intro.html

> I split them for no particular reason. I saw that control file provide
> libcg and libcggl so I create two packages. They can be merged. Maybe
> we can do a review of the package slit.
> /usr/include/* -> libcg-dev
> /usr/lib/* -> libcg
> remaining (doc, bin) -> nvidia-cg-toolkit or rename the package if you
> want. Maybe we can split all doc into a libcg-doc (or
> nvidia-cg-toolkit-doc) but my packager skill is beginner.

OK, I'd probably go for simply libcg + nvidia-cg-toolkit, for now, to
not deviate too much from Debian.

> I didn't understand anything on the prerm/postint stuff. What do you
> want to do exactly?

I think we can delete debian/*{prerm,postinst}
dh_makeshlibs adds ldconfig calls.

> Nvidia-cg-toolkit seems abandoned on debian. It didn't get any update
> from a long time (latest was on 19 Mar 2009). Current version is
> deprecated by Nvidia which send a "please upgade message" to all bts
> bug report ! For information there is another reverse-dependency :
> ogre-plugins-cgprogrammanager (at least on debian)

Yup, I did the last update here too. I don't want to take over
mainatinership of it in Debian, as I don't use it, though.

I should probably start the proceedings on getting it properly
orphaned...

There, did my good deed for the day: http://bugs.debian.org/649514

Hi Stefano,

I try to create a bazar branch but I failed, I only got latest debian version... So far I try those 2 braches
#bzr branch lp:ubuntu/nvidia-cg-toolkit
Most recent Ubuntu version: 3.0.0007-0ubuntu1
Packaging branch version: 2.1.0017.deb1+nmu2
Packaging branch status: OUT-OF-DATE

#bzr branch lp:ubuntu/nvidia-cg-toolkit -r 'tag:3.0.0007-0ubuntu1'
bzr: ERROR: No such tag: 3.0.0007-0ubuntu1

Could you tell me how I get your latest change. I didn't find neither a nvidia branch in your personal branch (maybe I miss it).

On prerm/postinst file subject, may I subject to build a package without the files then extract the binary package ("unp" or "ar -x") and check that default files are correct.

Thanks

The packaging branch for this package is out of date, because bzr-buildpackage doesn't support multiple orig tarballs yet, so bzr isn't usable on this package.

You can browse the contents of debs with file-roller and mc, or just unpack it, yes.

Bad luck, at least I could use UDD for others package now.

For whatever the reason, post* files are not included by default. So I keep them with libcg package.

>>There should be a build-depends on dpkg-dev (>= 1.16)
Debhelper 8.1.3 depends on dpkg-dev (>= 1.16) so I'm not sure it is needed actually.

Note I did not update the package version, you will do a better jobs than me. By the way a 2 time approach could be easier to handle.

Thanks, updated and uploading it now.

Yeah, that indirect debhelper dependency is OK. Normally, relying on indirect dependencies is a bad idea, but I think it's fine here, because we are explicitly depending on it for multi-arch support.

This bug was fixed in the package nvidia-cg-toolkit - 3.0.0016-0ubuntu1

---------------
nvidia-cg-toolkit (3.0.0016-0ubuntu1) precise; urgency=low

  [ Gregory Hainaut ]
  * Build for multiarch (LP: #811927)
    + Move library into libcg package. Update conflict accordingly.
    + Install so in multiarch directory
    + generate multiarch path in .install files
    + Bump debhelper dependency, need for ${misc:Pre-Depends} and dpkg >= 1.16

  [ Stefano Rivera ]
  * New upstream version
 -- Gregory Hainaut <email address hidden> Mon, 28 Nov 2011 18:48:59 +0200

Thanks you very much for your feedback and suggestions.