4:45 a.m.
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
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
5:37 a.m.
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.
--
Axel.Thimm at ATrpms.net
5:42 a.m.
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
6:07 a.m.
On 30/03/07, Axel Thimm <Axel.Thimm(a)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
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
6:31 a.m.
On Fri, Mar 30, 2007 at 01:07:07PM +0200, Mary Ellen Foster wrote:
On 30/03/07, Axel Thimm <Axel.Thimm(a)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?
--
Axel.Thimm at ATrpms.net
7:09 a.m.
On 30/03/07, Axel Thimm <Axel.Thimm(a)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
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
8:26 a.m.
New subject: Building a set of packages where some BuildRequire others
Le Ven 30 mars 2007 14:09, Mary Ellen Foster a écrit :
On 30/03/07, Axel Thimm <Axel.Thimm(a)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.
--
Nicolas Mailhot
8:32 a.m.
On 30/03/07, Nicolas Mailhot <nicolas.mailhot(a)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
http://homepages.inf.ed.ac.uk/mef/
8:48 a.m.
Mary Ellen Foster wrote:
On 30/03/07, Nicolas Mailhot <nicolas.mailhot(a)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.
10:56 a.m.
On 30/03/07, Ralf Corsepius <rc040203(a)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
--
Mary Ellen Foster
http://homepages.inf.ed.ac.uk/mef/
6230
days inactive
6230
days old
packaging@lists.fedoraproject.org
9 comments
6 participants
participants (6)
-
Axel Thimm -
Mary Ellen Foster -
Mary Ellen Foster -
Nicolas Mailhot -
Paul Howarth -
Ralf Corsepius