I would prefer to see #2 over #1. When deciding which packages to use a
user shouldn't have to deselect/select something multiple times or
figure out which is the right one. The package should be LAM. If there
are multiple rpms that are needed to support that, it should be a
package specific config option, perhaps automatically
determined/defaulted by the package code, if possible.

Mike

On Wed, 2003-03-12 at 09:20, Jeff Squyres wrote:
> So the question came up on the call this week about supporting libraries
> compiled with something other than gcc 2.x.  This would include LAM,
> MPICH, HDF5, PVM, and probably others.
> 
> Although this is obviously a Good Thing, what's the best way to do
> this?  For example, I can see some obvious compiler targets:
> 
> - gcc 2.9x
> - gcc 3.x
> - icc
> - ...?
> 
> Some questions (taking LAM as the example, although the issue is the
> same for all library packages):
> 
> 1. Should there be multiple LAM packages, one for each compiler?
> 
>    PRO: easy modularity; each package is identical in terms of
>         structure and content; only difference is which compiler was
>         used to make the RPMs
>    CON: lots of packages; could be confusing to user ("Do I want
>         lam-6.5.9-gcc-2.9x-x86 or lam-6.5.9-gcc-3.2-x86 or
>         lam-6.5.9-icc-x86 or...?")
> 
> 2. Or should the LAM package simply have multiple RPMs?
> 
>    PRO: only one package to maintain; no duplicated code in multiple
>         packages
>    PRO: choice of which default version to use becomes a configurator
>         issue
>    CON: ...?
> 
> 3. What versions of gcc 3.x do we support?  Since, in particular, the
>    C++ ABI changes so much from version to version, I would think that
>    we'd only want to support the latest and greatest -- MDK 9.0 ships
>    gcc 3.2, which, IIRC, was supposed to be the "good" one...?
> 
> Regardless of the answers between these, the package(s) may have to
> get a little smarter to know which RPMs they can install (e.g., can't
> install an icc-based RPM if icc is not installed).
> 
> Comments?
-- 
Michael Chase-Salerno           [EMAIL PROTECTED]
IBM Linux Systems Technology    Poughkeepsie, NY 
System Installation Suite       www.sisuite.org




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel

Reply via email to