On Fri, 1 Dec 2006, Kirk Wolf wrote:
> We are preparing to release a new commercial application which will
> support zSeries linux distros,
> and are hoping to get some advice and/or suggestions for packaging the
> product for zSeries.
Wow! Thanks for asking! Long response from me.
Summary at end of this note. Other comments interleaved.
> 1) "s390" (31 bit) architecture LSB 3.0 compatible RPM
> 2) "s390x" (64 bit) architecture LSB 3.0 compatible RPM
> 3) source rpm
> 4) source tarball
This is an excellent list.
There are some additional details not mentioned. See below.
Several have responded about the need for an automatic installation.
But that is the point behind RPM: automated installation including
record of inventory.
Dave Boyes mentioned 'autoconf' and the value of the source TAR file.
There is some ramp-up on a learning curve there. In any case,
be sure that your source tree builds with the standard recipe:
# download or copy from your media
# unpack the source TAR file, get into that directory
./configure
make
make install
If you can accomplish that will full-blown autoconf, so much the better.
> 1) RHEL 3.x is not LSB 3.0 compatible, ...
You can work around this.
You simply have to discard assumptions based on what the distributors
do and doc. While I am hugely thankful for SuSE and RedHat, you and
your customers are best served by keeping to a constant that they
do not define. While SuSE Linux is Linux, Linux is not SuSE.
Similarly, while RedHat Linux is Linux, Linux is not RedHat.
Biggest problem you'll have with lack of LSB compliance is the
location of the start-up script(s) and what is required of them.
> 2) For non-LSB3.0 environments, we would have instructions on how
> to do a source RPM install or a source tarball "make/make install".
> ...
Customers will have many reasons that they might need source.
Lack of LSB compliance is not necessarily one of them. See below.
But in this case, build the package outside of RPM control,
build it on a lowest common denominator, and then test that build
on all target distributions. THEN fall back to the source build.
You might need to avoid C++ for this to work.
Without starting a flame war over languages, might need to avoid C++
for plenty other reasons. My concern here is the mess imposed by
the run-time libraries for C++. If you go with C++, link statically.
> Even though the build is simple, will this be a issue with
> some z Linux customers?
This will always be and issue with some Linux customers, z or not.
> Based on feedback, we can really decide to ship the package formats
> that users seem to want/need, but we would *really* like to keep the
> binary packages to a small number. We would like to be able to use
> a single zLinux image to build binary packages.
This is the lowest common denominator I mentioned.
But you'll have to do rigorous testing. (But you're doing that
anyway, right??) In my time, I categorically refused to build
multiple RPMs where they were not needed. Customers will appreciate it.
It gets tricky when having to use other code that is "multiply built",
that is re-built on each release of every distro. Source RPM builds
lead you into this. This is why I recommend that you build OUTSIDE
of the control of RPM.
> It would be *ideal* for us to just ship source packages,
> but our intuition is that no matter how simple the
> build process, some customers will only want binaries
> (the opposite of my preference :-)
I share your sentiment.
*** SUMMARY ***
Build the package outside of RPM control. That is, DO NOT ship it
as built from the SRPM. You can and should still ship an SRPM.
Do an 'rpmbuild -bb' against a built and installed package.
Build on the lowest common denominator (oldest common distro).
Also, RPM is just one packaging tool.
See if you can support one or more of the others, at least in the lab,
to the extent that you are okay when customers turn out to want to
use it on a non-RPM Linux even if you don't document that support.
If some source is C++, statically link the C++ libs.
Support relocation! For the RPM packages, this is done by specifying
a prefix path in the spec file. The customer can then override the
prefix and get the whole thing installed in an alternate location.
(It's a little tricky if you have to place content under /etc
like an INIT script.) The recipe then looks like
./configure --prefix=/customer/specified/place
make
make install
which is supported by most autoconf-based packages.
If your package has server or daemon tasks, make your INIT script(s)
multi-platform capable. This is really really easy: INIT scripts that
are fully LSB compliant and yet also work on such platforms as HP-UX.
Should be fine on the pre-LSB Linux systems too. (For that matter,
should be okay on z/OS!)
Where your INIT scripts run depends on the platforms you support.
So if you don't yet run on HP-UX, then you won't yet care to script
that support. No biggie. I'm just saying that you need to dig into
the start/stop and other logic within the INIT schemes you do have.
-- R;
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
