Feat: rework cmakelists.txt to facilitate deb file creation.

[mostroot]

Description

Adds changes to the top level cmake_lists.txt to enable cpack creation of .deb files. In order to create the runtime and develop .deb files you will need to:

1. Build cuOpt
2. Navigate to cpp/build
3. run cpack -G DEB

This creates two .deb files for the architecture of the machine that cuOpt is built on.
For example: cuOpt_25.08.0_amd64-Development.deb and cuOpt_25.08.0_amd64-Runtime.deb

The runtime deb package contains the cuopt CLI, the mps reader.so and the cuopt.so.
The cuopt_CLI is installed in the /usr/local/bin directory
The .so files are installed in the /usr/local/lib directory

The development deb package contains the mps reader.so, the cuopt.so and the header files for the project all of which are installed in /usr/local/lib in a standard fashion.

The headers are in /usr/local/lib/cuopt

Note: There are items in the deb package creation that I took the liberty to fill, some of them may need changes.
Specifically these two lines:
set(CPACK_DEBIAN_DEV_PACKAGE_MAINTAINER "NVIDIA")
set(CPACK_DEBIAN_RUNTIME_PACKAGE_MAINTAINER "NVIDIA")
I assumed that is how you'd like the maintainer referenced.

Additionally the deb packages do not correctly reference their dependencies yet, i'm happy to follow up with that work if this looks likely to be merged.

Issue

#189

Checklist

• I am familiar with the Contributing Guidelines.
• Testing
  • New or existing tests cover these changes (Not added for the cmake changes)
  • Added tests (Compiling and deb installation works, unsure how you'd like a test for this)
  • Created an issue to follow-up
  • NA
• Documentation
  • The documentation is up to date with these changes
  • Added new documentation ( Happy to add the documentation just need to pointed to where you'd like the cpack instructions)
  • NA

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[rgsl888prabhu]

Thank you @mostroot for the issue and the PR, I wanted to understand the use case of deb package compared to pip wheel.

And also do we expect underlying dependencies to be available as deb package or expect users to install it by themselves.

As per my knowledge, there few dependencies which are header only, but there are dependencies which are in the form of conda or pip wheel package. So, we might not have all dependencies available as .deb package.

[mostroot]

From my testing, all of the dependencies are mostly contained in rapids and the base cuda instalation. I'll see what I can do to get the dependencies behaving via the deb route.

As far as the Usecase, it enables other packages like SimpleRose's solver to depend on the cuOpt deb package. We plan on self hosting a latest version of cuopt privately. It fits in with our existing stack being entirely installable via deb packages. This just provides a very scalable way to install on a distributed network of instances essentially.

The pip wheel route could work for us, but would require some scripting instead of existing deb package dependency linking.

[mostroot]

@rgsl888prabhu I looked into the dependency tracking for the deb file, in short its rather complicated. I can specify that it depends on a particular cuda-toolkit version in the file, but because of how the Nvidia cuda-toolkit versions are packaged I can't do something simple like: depends on cuda version 11 or greater.

In short the cuda-toolkit's are literally named: cuda-toolkit-12-1 or cuda-toolkit-12-8 cpack sees those as two completely different package names, not two versions of the same name. So I could set very strict requirements of a particular version like 12-8, but it wouldn't be installable on any system with another version of cuda-toolkit installed.

Because of this, I think the right route is to have this produce a deb file with no dependencies and assume that the user has cuda and the cuda-toolkit installed correctly. It's not perfect, a user could add specific dependencies for a particular version if they wanted their deployed systems to function correctly, or alternitively you could have a lengthy script that creates a ton of different deb files for each specific version of cuda and let the user pick the right one. I could take a stab at that solution, but I think it would be much more messy.

Happy to find some time to talk through it if you'd like. Let me know where you'd like me to take it.

Also @rgsl888prabhu that's a great one piece avatar you have :)

[rgsl888prabhu]

@rgsl888prabhu I looked into the dependency tracking for the deb file, in short its rather complicated. I can specify that it depends on a particular cuda-toolkit version in the file, but because of how the Nvidia cuda-toolkit versions are packaged I can't do something simple like: depends on cuda version 11 or greater.

In short the cuda-toolkit's are literally named: cuda-toolkit-12-1 or cuda-toolkit-12-8 cpack sees those as two completely different package names, not two versions of the same name. So I could set very strict requirements of a particular version like 12-8, but it wouldn't be installable on any system with another version of cuda-toolkit installed.

Because of this, I think the right route is to have this produce a deb file with no dependencies and assume that the user has cuda and the cuda-toolkit installed correctly. It's not perfect, a user could add specific dependencies for a particular version if they wanted their deployed systems to function correctly, or alternitively you could have a lengthy script that creates a ton of different deb files for each specific version of cuda and let the user pick the right one. I could take a stab at that solution, but I think it would be much more messy.

Happy to find some time to talk through it if you'd like. Let me know where you'd like me to take it.

Also @rgsl888prabhu that's a great one piece avatar you have :)

Thank you @mostroot for detailed findings, as of now we haven't had a particular request to maintain deb package from the community. And leaving dependency installation always raises more questions and issues. But I will discuss with team whether we can enable this as one more option through source code as independent lib without any dependencies, and advanced users like you can explore how you want to integrate it.

But I would also suggest you to take a look at integrating pip package since it would help with dependency and it would be easier to also install any new night-lies or releases.

: ) I am an OTAKU and like to watch Anime and Read Manga.

[vyasr]

From my testing, all of the dependencies are mostly contained in rapids and the base cuda instalation. I'll see what I can do to get the dependencies behaving via the deb route.

We don't have debs for the rest of RAPIDS either. There are discussions around moving in that direction in rapidsai/build-planning#45. If the cuopt team decides to move forward here, it would be ideal to find solutions that are reusable across other libraries too.

[rgsl888prabhu]

From my testing, all of the dependencies are mostly contained in rapids and the base cuda instalation. I'll see what I can do to get the dependencies behaving via the deb route.

We don't have debs for the rest of RAPIDS either. There are discussions around moving in that direction in rapidsai/build-planning#45. If the cuopt team decides to move forward here, it would be ideal to find solutions that are reusable across other libraries too.

Thank you @vyasr.