In article <[EMAIL PROTECTED]> you wrote:
> [...]
> I have a couple of questions regarding building packages combined with
> existing ones For example I am using the IBM version of apache since most
> admins love the interface (sigh) and for the extremely fine afpa module.
> I need to run php with it and want to adapt the package to it. What do I
> have to do ?
Do you talk about a binary-only package from IBM or a source-based one?
For source-based ones it is not different than for other software. For
binary-only vendor packages it is harder. What you usually have to do
in your OpenPKG packaging is to unpack the other packaging format and
re-package it with OpenPKG's RPM. See for example the "jdk-sun" or
"tsmc" packages in OpenPKG-CURRENT.
> What do I have to change if I get src rpm's fromv endors to be able to use
> them with OpenPKG.
We prefer the clean-room approach and did not care about existing
.spec's at all. We always start from scratch, because experience
showed that you are faster this way if you want to reach a 100% clean
packaging. The are multiple reasons for this. The main ones follow:
1. OpenPKG packages _have to_ be build-able under non-root
(for security and OS-trashing reasons)
2. OpenPKG packages _have to_ be build-able inside $RPM_BUILD_ROOT
(for correct file determination reasons)
3. OpenPKG package specifications _have to_ be all of the
same coding style. We're very pedantic about cleanness.
(for maintainance and consistency reasons)
And usually 95% of all RPM .spec's you find flying-around on the net do not
fulfill those requirements. Usually, because people do not care about those
points such a lot and because it is often not easy to "convince" a vendor
source to play this game. But for OpenPKG packages these points are a must.
And so it is usually always easier to package it from scratch. Although in
practice we usually use the template approach, i.e., take an existing OpenPKG
package's .spec, remove its particular parts and fill in the required parts
for the new package. Look into our CVS under openpkg-cvs/*/*.spec for over 200
examples of .spec files.
Nevertheless, as long as the license of the existing .spec permits it,
you are strongly advised to take over approaches and steps from there,
of course.
So, in short: we recommend to not convert .spec's to OpenPKG. But if you
really want, it works as long as you use the $RPM_BUILD_ROOT feature and
build the sources for %{l_prefix} (the variable in OpenPKG giving you
the file-system prefix of the OpenPKG installation).
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
