Joseph Kowalski wrote:
>> From: Alan Coopersmith <alan.coopersmith at sun.com>
> ...
>> Nicolas Williams wrote:
>>> IMO def*() should be contracted for using existing default files (and
>>> variables) *only*.
>>>
>>> For example, if there was a new GUI utility that needed to process
>>> /etc/default/su in order to be consistent with su(1) then it should use
>>> libcmd:def*() under contract, but a new utility that needed some way to
>>> store configuration above and beyond what exists now in /etc/default
>>> must NOT use libcmd:def*(), nor default-style configuration files, even
>>> if it lives in ON.
>> So should it be "Obsolete Consolidation Private"?
> 
> Yep, it should be "Obsolete <whatever we agree to".

This isn't really this case but.....

I don't agree that it should be Obsolete.  There are certainly some 
/etc/default files that in the brave new world of SMF are better 
represented as properties on the appropriate SMF service.  As the 
original creator of /etc/default/nfs I'd happily say that is one of them.

On the other hand there are others where that just does not fix because 
the file in /etc/default does NOT represent a service but a command
that has a need for some system wide configuration.

I don't think they are the best interfaces around but they work and
they are simple, and I've used them a reasonable amount.  Personally
I'd just say make them Committed.   The ARC (and 3rd parties not 
shipping as part of OpenSolaris projects) should make the architecture 
judgment as to wither or not SMF is the appropriate repository of the 
information, this has nothing what so ever to do with the interface 
taxonomy given to the def*() interfaces in libcmd.

Attached is my swag on what is and is not a service, 64% or the 28 files 
on the snv_46 system I looked at could in opinion could be stored in SMF.

-- 
Darren J Moffat
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: def
URL: 
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20060927/96870545/attachment.ksh>

Reply via email to