RE: Supporting multiple Linux platforms

["Wichmann, Mats D" <mats d wichmann intel com>]

rpm-list-bounces redhat com wrote:
> On Thu, Oct 04, 2007 at 12:22:16PM -0400, Jorge M. wrote:
> 
>>   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.

>>    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.

>>    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. 
> 
>>    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.