I'm currently trying to create Fedora-compliant packages of the Internet Communications Engine (Ice) -- object-oriented middleware, see http://www.zeroc.com/ for details. They used to provide a yum repository for Fedora, but with the new version they've stopped. I'm now working on adapt their SRPMS to Fedora packaging standards. (If anyone else has done / is doing this, let me know!)
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 -- 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.
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.
Thanks for any suggestions!
MEF
On Fri, Mar 30, 2007 at 11:45:30AM +0200, Mary Ellen Foster wrote:
I'm currently trying to create Fedora-compliant packages of the Internet Communications Engine (Ice) -- object-oriented middleware, see http://www.zeroc.com/ for details. They used to provide a yum repository for Fedora, but with the new version they've stopped. I'm now working on adapt their SRPMS to Fedora packaging standards. (If anyone else has done / is doing this, let me know!)
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 -- 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.
Are ice-java-devel and ice-java subpackages of the same build? If yes, you can use slice2java within one specfile. If not, then the naming is a bit awkward, but what would stop you from using BuildRequires: ice-java-devel in ice-java? Or is ice-java-devel dependent on ice-java, e.g. you have a circular build dependency, e.g. a bootstraping problem?
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.
If it's a bootstraping problem, either do ice-java and ice-java-devel in one source package, so no build dependencies to external packages arise, or if that's not an option you need some special bootstraping attendance by both the FPC and the build admins.
On 30/03/07, Axel Thimm Axel.Thimm@atrpms.net wrote:
Are ice-java-devel and ice-java subpackages of the same build? If yes, you can use slice2java within one specfile. If not, then the naming is a bit awkward, but what would stop you from using BuildRequires: ice-java-devel in ice-java? Or is ice-java-devel dependent on ice-java, e.g. you have a circular build dependency, e.g. a bootstraping problem?
I'm using the upstream package names for now; maybe I should rename them to "ice-java" and "ice-java-runtime" or something like that. Unfortunately, these two packages can't be built from the same SRPM, because the runtime is noarch (only jar files) while the development stuff contains binaries (a translator written in C++ to convert ice files into Java source).
Or is it possible to use the same SRPM to generate both arch and noarch packages simultaneously? If so, that would make my life simpler ...
I'll try to put up some packages for review in the next day or two.
MEF
On Fri, Mar 30, 2007 at 01:07:07PM +0200, Mary Ellen Foster wrote:
On 30/03/07, Axel Thimm Axel.Thimm@atrpms.net wrote:
Are ice-java-devel and ice-java subpackages of the same build? If yes, you can use slice2java within one specfile. If not, then the naming is a bit awkward, but what would stop you from using BuildRequires: ice-java-devel in ice-java? Or is ice-java-devel dependent on ice-java, e.g. you have a circular build dependency, e.g. a bootstraping problem?
I'm using the upstream package names for now; maybe I should rename them to "ice-java" and "ice-java-runtime" or something like that. Unfortunately, these two packages can't be built from the same SRPM, because the runtime is noarch (only jar files) while the development stuff contains binaries (a translator written in C++ to convert ice files into Java source).
Or is it possible to use the same SRPM to generate both arch and noarch packages simultaneously? If so, that would make my life simpler ...
No, not in the same build.
The question is now, do "ice-java" and "ice-java-runtime" both require each other at build-time?
On 30/03/07, Axel Thimm Axel.Thimm@atrpms.net wrote:
Or is it possible to use the same SRPM to generate both arch and noarch packages simultaneously? If so, that would make my life simpler ...
No, not in the same build.
The question is now, do "ice-java" and "ice-java-runtime" both require each other at build-time?
No; the runtime requires the development stuff, but not vice versa. I'm making packages right now in which the runtime builds its own private copy of slice2java and uses it in the build process. This seems to be easier as a first step than enforcing a particular build and installation order.
MEF
Le Ven 30 mars 2007 14:09, Mary Ellen Foster a écrit :
On 30/03/07, Axel Thimm Axel.Thimm@atrpms.net wrote:
Or is it possible to use the same SRPM to generate both arch and noarch packages simultaneously? If so, that would make my life simpler ...
No, not in the same build.
The question is now, do "ice-java" and "ice-java-runtime" both require each other at build-time?
No; the runtime requires the development stuff, but not vice versa.
So what's the problem with building devel first ? That's trivially expressed with buildrequires.
On 30/03/07, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
So what's the problem with building devel first ? That's trivially expressed with buildrequires.
Building in mock, I think ... or is there a trick to make that work?
MEF
Mary Ellen Foster wrote:
On 30/03/07, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
So what's the problem with building devel first ? That's trivially expressed with buildrequires.
Building in mock, I think ... or is there a trick to make that work?
Create a local repository for your development activities, and add it to your mock configuration.
Build the devel package and put it in your local repository. It will then be available in mock for your subsequent runtime build, which will have the devel package as a buildrequire.
Paul.
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
On 30/03/07, Ralf Corsepius rc040203@freenet.de wrote:
I'd suggest you to submit your package for review, such that others can actively assist you.
I've just submitted initial packages for review here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234612
I'd be glad for any suggestions! :)
MEF
packaging@lists.fedoraproject.org
-
Axel Thimm -
Mary Ellen Foster -
Mary Ellen Foster -
Nicolas Mailhot -
Paul Howarth -
Ralf Corsepius