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 "bootstrapping". Unfortunately, there is no general recipe to resolve such kind of problems. > 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. Ralf -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
