[Fedora-packaging] Building a set of packages where some BuildRequire others

Ralf Corsepius 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
design flaw.

- 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 mailing list