On Sun, 2007-03-18 at 14:06 -0400, Jeff Squyres wrote: > I think that Doug is trying to say that our default location should > be /usr (not /usr/local/ofed). That would seem to solve several issues: > > - will automatically generate conflicts with the RHEL OFED RPMs > - less muckery with finding libraries and header files > - can claim to be FHS complaint > - user *can* change the default location to elsewhere if they want to > > If it's a simple issue to change our default,
If it's *not* a simple issue to change the default (and in truth, it does take some forethought and planning to get it right), then the much more important question is why would you expect the user to do that work themselves? > is the only reason > *not* to do it the historical precedent of prior community OFED > versions? If so, that argument is somewhat diluted because a) we (as > a community) are encouraging users to upgrade, and b) RH started is > already shipping OFED RPMs that live in /usr. c) like every other initially /usr/local package, there comes a time to grow up. If historical precedent meant anything, I'm sure X would still be in /usr/local. > > > > On Mar 18, 2007, at 11:42 AM, Doug Ledford wrote: > > > On Sun, 2007-03-18 at 13:51 +0200, Michael S. Tsirkin wrote: > >>> On Mar 18, 2007, at 7:15 AM, Michael S. Tsirkin wrote: > >>> > >>>>> I think you're missing Doug's point. There is currently no > >>>>> mechanism > >>>>> for the user to know that they're installing 2 potentially > >>>>> conflicting versions of the same software (OFED). > >>>> > >>>> That's a good point, although not entirely correct. AFAIK OFED > >>>> installer > >>>> currently attempts to detect and warn about conflicting > >>>> libraries, this > >>>> logic probably can be improved. > >>> > >>> > >>> > >>> Quoting Jeff Squyres <[EMAIL PROTECTED]>: > >>> Subject: Re: [ofa-general] OFED 1.2 Feb-26 meeting summary > >>> > >>> That seems like chasing our tail: adding more logic/work to > >>> replicate > >>> a mechanism that is already available (*and* making sure that we > >>> keep > >>> this logic up-to-date with all the OFED distributions out there -- > >>> which seems like a losing proposition). RPM can detect this kind of > >>> conflict and prevent it. Why aren't we using it? > >>> > >>> Oh, right, because we're doing several kinds of non-standard things > >>> that preclude us from doing so. :-) > >> > >> Right. But the user *can* the prefix to /usr, and RPM will detect > >> conflicts > >> then, isn't that right? > > > > This is a joke, right? You can't *really* be serious. If you are, > > then > > I suggest the EWG change the acronym for OFED to Open Fabrics > > Experimental Distribution because no enterprise customer I know of > > would > > accept the above suggestion that they change the spec file and > > recompile > > just to get RPM to do its job as reasonable for an enterprise software > > package. > > > > -- > > Doug Ledford <[EMAIL PROTECTED]> > > GPG KeyID: CFBFF194 > > http://people.redhat.com/dledford > > > > Infiniband specific RPMs available at > > http://people.redhat.com/dledford/Infiniband > > -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
