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


Richard Shaw <hobbe...@...>
 

On Fri, Nov 18, 2011 at 9:40 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
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??)
Usually it's the packagers job to decide on how to break up the
packages as the guidelines differ somewhat between distros, but
documented suggestions are very welcome.


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.
Does ocio include significant testing yet? I'm sure RPM does and deb
based systems probably also have the ability to test the builds during
the building process. In RPM's this is done in the %check section. I'd
have to look it up but I'm pretty sure exiting with anything other
than "0" will fail the build. This may do a lot to ease the burden of
having to worry about the versions of yaml-cpp and tinyxml the host
system uses.


....
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.
If it helps, here's the current versions of the software in ext on my
Fedora 15 system:

tinyxml-devel-2.6.1-2.fc15.x86_64
yaml-cpp-devel-0.2.5-2.fc15.x86_64
python-docutils-0.8-0.1.20110517svn7036.fc15.noarch
python-jinja2-2.5.5-4.fc15.noarch
lcms2-devel-2.2-1.fc15.x86_64
python-pygments-1.4-1.fc15.noarch
python-setuptools-0.6.24-1.fc15.noarch
python-sphinx-1.0.7-2.fc15.noarch

I can get the same information for Fedora 16 and EL 6 if it would help
(EL means RHEL 6 and derivatives, CentOS, SL, etc.). Are you worried
about EL 5? I would think that's the oldest EL that would matter.


Later on when OpenImageIO has be also successfully been packaged we could
have another package for ocioconvert and ociodisplay.
Do you mean for other distro's? oiio is already in Fedora as I'm the
maintainer for it. I haven't packaged it for any EL's but that could
be added fairly easily.


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.
Yes, since nuke and Truelight are non-free they will not be in Fedora.
If someone wants to build a commercial system based on Fedora they can
use the source RPM and build their own packages very easily. That's
the nice thing about using a source RPM. Most of the hard work is done
for you.

Thanks,
Richard

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