[ofa-general] OFED 1.2 Feb-26 meeting summary

[Doug Ledford]

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 <jsquyres at cisco.com>:
> >>> 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 <dledford at redhat.com>
> >               GPG KeyID: CFBFF194
> >               http://people.redhat.com/dledford
> >
> > Infiniband specific RPMs available at
> >               http://people.redhat.com/dledford/Infiniband
> 
> 
-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20070318/48b70a11/attachment.sig>