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
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
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.