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


Jeremy Selan <jeremy...@...>
 

So i've learned a lot about packaging these last few days!  Who knew there was so much to it? ;)

For those who want to come up to speed as well, these links are great places to start:


First off, I'm now totally sold on us (eventually) using the system install for all dependencies. (Which doesnt mean we cant ship with those in ext, we just need to play nicely with the system installed ones)

And for those interested, here is Richard's the fedora listserv link:
(thanks Richard for asking)

My hesitancy to pull out yaml / tinyxml was only based on wanting to guarantee serialization compatibility, but I now believe all of my concerns about serialization precision, etc, can be addressed with additional unit tests.  That's better than just locking down to a single library anyways.  Perhaps we could make the unit tests part of the build process, so if they fail we can mark the install as failed too?

The fedora team also mentions that it's okay to include bundled libs for convenience, as long as you defer to the system installs if they exist. (or something similar)  That seems like the best of both worlds (with the new unit tests, of course).

For md5, we dont have to worry about including the source code as the version we use is an accepted copylib.  The same also applies to pystring. (I will update the pystring website docs to make this explicit) ;)

In terms of how we split up the libs, I'm willing to defer to experts.  But if I had to wager a guess for what ocio 'core' would consist of, I'd consider it:

- src
- core (lib + shell apps)
- dev (headers etc)

which would require the dependencies:
 lcms, tinyxml, yaml-cpp

I'd probably leave out nuke / mari from all installs (other than the source), as they'll be disted with the apps anyways.  So that just leaves the docs targets remaining?

Also, in terms of the shell apps, the two that depend on oiio (ociodisplay,ocioconvert) are not really intended to be used or installed necessarily, they're really more included as simple working code examples.   But the other command-line apps (ociocheck, ocio2icc, ociobakelut) are useful parts of the base install.

As far as python is concerned, it'd be great if it were part of the core install, but how does this work with regards to python versions?  With the new installation location, is it possible to have both 2.6 / 2.7 installs on the same system? (not sure if this is critical or not)


ACTION ITEMS:

- Colin - Getting OCIO ready for inclusion on distros is going to take a bit of work, and I see no reason to delay the cpack installs.  So COLIN, why dont you start on the 'core' install?  Let us know if there's anything holding you up?

- Jeremy (me): I'll need to add unit tests for serialization, and to push our yamlcpp edit upstream.  I'll also update to the latest version of all serialization libs and make sure everything still works fine.  I'll also update pystring's website to clarify its expected use as a copylib.

- Richard.  Any thoughts on how we can make the unit tests part of the installation / build process? 

-- Jeremy

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