[Fedora-packaging] Building a set of packages where some BuildRequire others
rc040203 at freenet.de
Fri Mar 30 10:42:55 UTC 2007
On Fri, 2007-03-30 at 11:45 +0200, Mary Ellen Foster wrote:
> I've managed to create a few packages, in the process learning a lot
> more about RPM tricks and so on. One issue I'm having -- and I'm
> pretty sure it's unavoidable
Well, it must be avoidable, ... ;)
> -- is that many of the packages have
> build-time requirements on other packages. For example, the tool to
> translate ice interfaces into Java code is called "slice2java" and is
> part of the ice-java-devel package; this tool is then needed to build
> the ice-java runtime package.
This problem is commonly known as "circular package dependencies" and as
Unfortunately, there is no general recipe to resolve such kind of
> What's the accepted way of building something with this type of
> constraints in mock? Should I just build temporary versions of the
> necessary tools as needed (e.g., let ice-java compile its own version
> of "slice2java" just for use in the build process)? I'd rather not do
> that, but if it's necessary I can do things that way.
This would be a means of least resort.
The problem you describe sounds like the classical "using built-tool
generated sources" to me.
Normally such issues can be resolved by one of the steps below:
- Serialize building:
First build the tool's minial infrastructure, then the tool, then the
final package. If this isn't possible, upstream suffers from a severe
- Ship pregenerated versions instead of building them on the fly:
I.e. add a patch containing all those files which should be generated by
a tool, then don't use this tool. This is the approach commonly applied
to yacc/lex sources.
- Incremental building:
Build the package using the "-1" version as tools. This is error prone
and risky (This approach will break should a package change
significantly between version)
- Include a prebuild binary of the tool into the sources.
Very hard to handle in practice.
Fortunately, in most cases, circular deps indicate packaging bugs, which
can be circumvented by changing a package's sub-package split and
applying the first 2 steps from my list above.
> Thanks for any suggestions!
I'd suggest you to submit your package for review, such that others can
actively assist you.
More information about the Fedora-packaging