[ofa-general] RE: compat-dapl-1.2.10 install bogosity

[Doug Ledford]

On Thu, 2008-09-18 at 10:40 -0700, Davis, Arlin R wrote:
> 
> >> However, even once you fix that, modifying user configuration files
> >> without their consent as part of make install is just a 
> >*BAD* idea.  The
> >> only time you should ever do anything like this is when you just flat
> >> don't care about things like rpm packaging (or apt 
> >packaging) and having
> >> the files on your system trackable, verifiable, erasable, 
> >etc.  Install
> >> methods that do this sort of thing are a good way to really alienate
> >> people in a position like me ;-)
> >
> >Turns out the dapl-2 package was doing this to.  I've attached 
> >the patch
> >I used to solve the problem.  I still don't know if I'd go around
> >editing user config files on install/uninstall though.
> >
> 
> Thanks, I will get these changes in as soon as possible. These changes 
> were driven by the fact that there are other DAPL provider vendors 
> that share this same configuration file, all adding/removing entries for
> 
> their specific provider. What is the proper way to handle the case
> where packages need to add/remove entries in a shared configuration 
> file?

Multiple options.  Lots of people never change the defaults, so you
could just make the default work without any config file entries at all
and then just use entries to over ride the defaults.  Or you can do like
lots of various configurable programs do know a days and make a
directory for people to drop individual config files into and parse all
those individual files.

-- 
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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20080918/43c32e0b/attachment.sig>