Building two packages dependent on each other?

Richard Shaw hobbes1069 at gmail.com
Sat Dec 14 13:10:28 UTC 2013


On Sat, Dec 14, 2013 at 5:56 AM, Michael Schwendt <mschwendt at gmail.com>wrote:

> On Fri, 13 Dec 2013 22:07:21 -0600, Richard Shaw wrote:
>
> > I maintain two package, OpenImageIO and OpenColorIO, which can optionally
> > depend on each other. During the review process I intentionally decided
> > that it was more important for OpenImageIO to depend on OpenColorIO as it
> > uses the latter for color management.
> >
> > OpenColorIO is not a library, but a binary requirement. It can optionally
> > build two binaries that use OpenImageIO. Until now this has not been a
> > problem but now I have gotten a request to build the binaries.
>

Ok, I slightly misspoke here, OpenColorIO is a library, but the only
dependency on OpenImageIO is from the utility binaries...


> >
> > This almost seems to be bootstrapping but I'm not quite sure I need to go
> > that far...
> >
> > Since both are established packages, if one is updated, wouldn't the only
> > consequence be that once I build the updated package, I would need to
> also
> > rebuild the other package (after adding the former as a buildroot
> override).
> >
> > Am I missing something, or is it that easy?
>
> It may be even easier. You only need a buildroot override, if the
> build of OpenImageIO that's available in the buildroot (since it has
> been published before) is not API-compatible with what OpenColorIO wants.
> For future updates/upgrades of OpenImageIO, rebuilds of OpenColorIO would
> only be needed for ABI/API changes in OpenImageIO.


Thanks! I was hoping it was that easy. Upstream is pretty good about not
breaking API/ABI but I usually check with abi-compliance-checker anyway
since OpenImageIO is needed by blender and I'm not the primary maintainer
for it.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131214/650e022f/attachment.html>


More information about the devel mailing list