Re: Handling of bundled apps/libraries for Linux distro packaging.


Malcolm Humphreys <malcolmh...@...>
 

Off list Jeremy, Colin and myself were chatting about this when talking about the windows build.

....
We need to have a consensus on how the project will be split up into packages (ie different sets of rpm's / debs etc).

Something along the lines of
- src
- core (lib + shell apps)
- dev (headers etc)
- gui apps (qt dependancy)
- nuke
- mari
- python (this could be part of core??)

Depending on if the goal is to get these packages included as part of the base linux distributions this creates a bit of work with the bundled in dependancies. To me this feels like a second step on getting ocio accepted into the most relevant distributions.
....

Thinking about this more it doesn't feel like we need to work out how to package everything just the main bits. Something like (note. these would map to the install options in the NIS installer on windows):
- OpenColorIO-src-1.0.1
- OpenColorIO-core-1.0.1
  [ libOpenColorIO, headers, ocio2icc, ociobakelut, ociocheck ]
- OpenColorIO-python{ver}-1.0.1
- OpenColorIO-docs-1.0.1
  [ html, pdf, man (need to add)]

OpenColorIO-core-1.0.1 would depend on lcms2-2.1, tinyxml-2.6.1, yaml-cpp-??, pystring-?? and possibly the md5 code.

Later on when OpenImageIO has be also successfully been packaged we could have another package for ocioconvert and ociodisplay.

The nuke and mari code probably can be left to be compiled/used on a need basis as this is pretty site dependant setup wise.

Thoughts?

Do we have to worry about have different compiler versions of the core package, depending on which host app it might be used in?

.malcolm


On 17/11/2011, at 4:06 PM, Richard wrote:

Placeholder for continued discussion from:


Join ocio-dev@lists.aswf.io to automatically receive all group messages.