Supporting multiple Linux platforms

[Jorge M.]

Hi,
I need to create installers for a product in multiple Unix variants and
Windows: Linux RedHat, Suse, SunOS,HP-UX, AIX, Win2k, Win2003, ...

We decided to use native installers, therefore I need to create an RPM
package for Linux. The product is supported in multiple versions of RedHat
Linux: RH3, RH4, RH5 and in multiple architectures 32 and 64-bit.
The application runs mainly in Java, but there is a supporting set of
binaries. We have a different set of binaries for each Linux platform.

I have been creating a single RPM, including the binaries for all Linux
platforms and using scripts to copy the right set of binaries to our app
"bin" folder and removing all other platform binaries.

Nevertheless, the built-in dependency processing does not allow me to
install the package because all lib dependencies for all platforms cannot be
satisfied.

I need some advice. Should I break my package into multiple RPMs?
I would really like to minimize the number of RPMs that I need to create.
Is it "wrong" to create a single RPM for all OSversion-architecture ? How
do I avoid the dependency checking? Should I follow a different path?

I already have to create multiple installers -one for each OS we support-
and I would like to keep the number of installers to a minimum.
Since we support multiple OS and we decided to use native installers, we
are having a big learning curve, since we need to be well versed in creating
RPM packages for Linux, MSI installers for Windows, Solaris packages and SD
packages for HP-UX. Minimizing the complexity on the packaging is key for
maintainability

Thanks in advance for your help.

-Jorge

[Jos Vos]

Post by Jorge M.
We decided to use native installers, therefore I need to create an RPM
package for Linux. The product is supported in multiple versions of RedHat
Linux: RH3, RH4, RH5 and in multiple architectures 32 and 64-bit.
The application runs mainly in Java, but there is a supporting set of
binaries. We have a different set of binaries for each Linux platform.
I have been creating a single RPM, including the binaries for all Linux
platforms and using scripts to copy the right set of binaries to our app
"bin" folder and removing all other platform binaries.

Wrong approach, IMHO.

Post by Jorge M.
Nevertheless, the built-in dependency processing does not allow me to
install the package because all lib dependencies for all platforms cannot be
satisfied.

Which is correct.

Post by Jorge M.
I need some advice. Should I break my package into multiple RPMs?

Yes. That is, have *one* src.rpm and create a binary rpm for every
platform/arch.

Post by Jorge M.
I would really like to minimize the number of RPMs that I need to create.

Why? If you have one src.rpm, it is very manageable, although you need
to build the binary rpm on each platform/architecture combination that
you want to support.

Post by Jorge M.
Is it "wrong" to create a single RPM for all OSversion-architecture ? How
do I avoid the dependency checking? Should I follow a different path?

You can avoid dependency generation, but you shouldn't, as this is not
necessary in your case.

In your %install (and maybe other sections), use conditional (%if) code
to differentiate between the various RHEL versions and architectures and
copy only the corresponding binaries to the target root. If needed, also
use conditionals in the %files section. Also, use some macro for the
RHEL version in your Release tag, to differentiate the various binary
rpm's for the same architecture.

Your problem is really easy to solve in a correct way.

[Wichmann, Mats D]

Post by Jos Vos

Post by Jorge M.
We decided to use native installers, therefore I need to create an
RPM package for Linux. The product is supported in multiple
versions of RedHat Linux: RH3, RH4, RH5 and in multiple
architectures 32 and 64-bit. The application runs mainly in Java,
but there is a supporting set of binaries. We have a different set
of binaries for each Linux platform.
I have been creating a single RPM, including the binaries for all
Linux platforms and using scripts to copy the right set of binaries
to our app "bin" folder and removing all other platform binaries.

Wrong approach, IMHO.

Yeah, this means the package database doesn't match what's installed,
this is definitely not a good idea.

Post by Jos Vos

Post by Jorge M.
Nevertheless, the built-in dependency processing does not allow
me to install the package because all lib dependencies for all
platforms cannot be satisfied.

Which is correct.

As noted elsewhere, you could try building on your "lowest common
denominator" and see if that works for you. You could also take
a look at LSB, where the single dependency "lsb" abstracts away
some of the details of library stuff - but only those things that
are covered by the LSB spec, which may or may not be enough for you.

Post by Jos Vos

Post by Jorge M.
I need some advice. Should I break my package into multiple RPMs?

Yes. That is, have *one* src.rpm and create a binary rpm for every
platform/arch.

Post by Jorge M.
I would really like to minimize the number of RPMs that I need to create.

Why? If you have one src.rpm, it is very manageable, although you
need to build the binary rpm on each platform/architecture
combination that you want to support.

Having to build it everywhere is somewhat of a burden, depending on
how much gear you want to have sitting around (virtual machines
can help here). But I do agree that getting your portability at
the level of the srpm seems like the cleanest approach.

[Jorge M.]

Hi Jos, Jeff, Leland, Bob, Mats:

Thanks a lot for your comments.
Seems all of you agree that a single RPM is not the best approach.
I will have to look deeper into the RPM technology; at least now I know what
to look for and what others expect for RPM packages.

-Jorge

[Jeff Johnson]

Post by Jorge M.
Hi,
I need to create installers for a product in multiple Unix
variants and Windows: Linux RedHat, Suse, SunOS,HP-UX, AIX, Win2k,
Win2003, ...
We decided to use native installers, therefore I need to create an
RPM package for Linux. The product is supported in multiple
versions of RedHat Linux: RH3, RH4, RH5 and in multiple
architectures 32 and 64-bit.
The application runs mainly in Java, but there is a supporting set
of binaries. We have a different set of binaries for each Linux
platform.
I have been creating a single RPM, including the binaries for all
Linux platforms and using scripts to copy the right set of binaries
to our app "bin" folder and removing all other platform binaries.
Nevertheless, the built-in dependency processing does not allow
me to install the package because all lib dependencies for all
platforms cannot be satisfied.

Dependencies reflect the linkage needs of the binaries in the package,
not otherwise.

If your application actually runs without recompilation on all the
linux platforms, then build
on the oldest platform often simplifies the packaging tasks. linux
often supplies backward (i.e. to
older libraries) even if not forward compatibility.

Post by Jorge M.
I need some advice. Should I break my package into multiple RPMs?

Understand the reason for splitting first. For java, you might be able
to have
a common "noarch" package shared amongst all platforms, with a per-arch
package that isolates per-platform changes.

Post by Jorge M.
I would really like to minimize the number of RPMs that I need to create.

Well I'd like to minimize the number of vendor's that absolutely
__MUST__
do things differently to distinguish their distro products. Not gonna
happen ;-)

Post by Jorge M.
Is it "wrong" to create a single RPM for all OSversion-
architecture ? How do I avoid the dependency checking? Should I
follow a different path?

No "wrong", but perhaps not going to work. Again dependencies are just
a reflection of
underlying realities. If different libraries are actually needed, then
the dependencies
will differ too. Avoiding dependency checking will just move the real
problem elsewhere, like
your application will not run because of missing libraries.

Meanwhile,
rpm -qp --filerequire yourpkg*.rpm
will show which files are responsible for a dependency.

Doing chmod -x %{buildroot}/path/to/file will disable the extraction
of dependencies for those file(s).

Add %attr(0755,-,-) to the entry in the %files manifest if execute
bits are needed
when installed.

There is no different path once you have decided "native installers" ;-)

Post by Jorge M.
I already have to create multiple installers -one for each OS we
support- and I would like to keep the number of installers to a
minimum.
Since we support multiple OS and we decided to use native
installers, we are having a big learning curve, since we need to be
well versed in creating RPM packages for Linux, MSI installers for
Windows, Solaris packages and SD packages for HP-UX. Minimizing the
complexity on the packaging is key for maintainability

Yep.

73 de Jeff

[Leland Ray]

Post by Jorge M.
I need to create installers for a product in

multiple >Unix variants and Windows: Linux RedHat,
Suse, >SunOS,HP-UX, AIX, Win2k, Win2003, ...

rpm is really a component installer, and most products
these days are constructed from a variety of
components. For the products I do with rpm, I find it
much easier to split into multiple rpms and use a yum
repository (or something like it) to install. Also,
prerequisites that might not be normally installed
with a distribution can get automatically installed,
that way. Finally, I tend to separately package any
3rd party libraries I am using. This has an added
benefit in it keeps the licensing people happier.

Do I understand that you have a single binary
requirement? In other words, you do a single Linux
build, and that build must work on all the
distributions of Linux you support? If yes, its going
to take some research on your part to determine the
configuration of your build machine. You'll need, for
instance, a glibc which has an old enough version that
it will encompass all the distributions you target.
You may also need to package compatibility rpms for
some distributions.

There is also the option of building on every system
you support. May or may not be practical for your
situation, often QA requirements keep that from being
the right approach.


____________________________________________________________________________________
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

[Valery Reznic]

Post by Leland Ray

Post by Jorge M.
I need to create installers for a product in

multiple >Unix variants and Windows: Linux RedHat,
Suse, >SunOS,HP-UX, AIX, Win2k, Win2003, ...
rpm is really a component installer, and most
products
these days are constructed from a variety of
components. For the products I do with rpm, I find
it
much easier to split into multiple rpms and use a
yum
repository (or something like it) to install. Also,
prerequisites that might not be normally installed
with a distribution can get automatically installed,
that way. Finally, I tend to separately package any
3rd party libraries I am using. This has an added
benefit in it keeps the licensing people happier.
Do I understand that you have a single binary
requirement? In other words, you do a single Linux
build, and that build must work on all the
distributions of Linux you support? If yes, its
going
to take some research on your part to determine the
configuration of your build machine. You'll need,
for

Another option to deal with applications binary
portability is using tools like statifier
(http://statifier.sf.net) or Ermine
(http://www.magicErmine.com)
Those tools create self-contained executable from exe
and all it's shared libraries, so resulting file have
no dependebcies (only minimal kernel version)

Valery.

Post by Leland Ray
instance, a glibc which has an old enough version
that
it will encompass all the distributions you target.
You may also need to package compatibility rpms for
some distributions.
There is also the option of building on every system
you support. May or may not be practical for your
situation, often QA requirements keep that from
being
the right approach.

____________________________________________________________________________________

Post by Leland Ray
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search

http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

Post by Leland Ray
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting

[Bob Proulx]

Post by Jorge M.
I have been creating a single RPM, including the binaries for all Linux
platforms and using scripts to copy the right set of binaries to our app
"bin" folder and removing all other platform binaries.

That is completely in conflict with the idea of using native
installers IMNHO. Basically you are working against the package
manager. As a consumer of these I *hate* those types of rpms and
would reject them and would feel the need to repackage them myself in
order to use your product.

Post by Jorge M.
Nevertheless, the built-in dependency processing does not allow me to
install the package because all lib dependencies for all platforms cannot be
satisfied.

That is correct because you probably can't satify all of the
dependencies all of the time creating an empty set.

Post by Jorge M.
I need some advice. Should I break my package into multiple RPMs?

Yes. Strongly advise yes.

Post by Jorge M.
I would really like to minimize the number of RPMs that I need to create.
Is it "wrong" to create a single RPM for all OSversion-architecture ? How
do I avoid the dependency checking? Should I follow a different path?

Build on the oldest common denominator that runs on all of your
supported systems. That will most likely run on later platforms. The
one particular place where it does not is when libraries change and
the older one is removed from newer systems. You would need to build
a new rpm on that system for use forward of that point then.

Post by Jorge M.
Since we support multiple OS and we decided to use native
installers,

Supporting native installers is good. But personally I feel that if
they are not going to be used natively then it is better simply to
supply an image file, such as a tar.gz image. It is better to play it
plainly and honestly rather than simply giving "lip service" to using
a package manager if it is simply going to be faked.

Post by Jorge M.
we are having a big learning curve, since we need to be well versed
in creating RPM packages for Linux, MSI installers for Windows,
Solaris packages and SD packages for HP-UX. Minimizing the
complexity on the packaging is key for maintainability

You have set up a big job ahead of you. But taking shortcuts actually
makes things harder and creates problems.

Bob