James Carlson wrote:
> UNIX admin writes:
>
>>> However, for stuff that's integrated in OpenSolaris
>>> -- and especially
>>> things in ON -- that's incorrect. We intentionally
>>> use explicit
>>> directory definitions on the foundation packages --
>>> and SUNWdmfe is
>>> one of those.
>>>
>> I can well understand that. Although, you are aware of the fact that, the
>> more packages set perms explicitly, the higher the chance that one of those
>> will set them incorrectly?
>>
>
> Of course. That's why the build process checks those (see checkproto
> and protocmp).
>
>
>> That's just statistics. Or do all your developers, bar none, know exactly at
>> all times what the perms are supposed to be? If that's the case, you've got
>> some seriously disciplined development, and that's something to admire.
>>
>
> Thanks.
>
<grin>
>
>>>> e none kernel/drv/dmfe.conf 0644 root sys
>>>>
>>> Possibly. Though the thought of people hacking away
>>> at driver.conf
>>> files is traumatizing.
>>>
>> Technically speaking, any files that is meant to be edited (.cf .conf and so
>> on), should be "editable".
>>
>
> Agreed. The quibble is with "meant to." Using driver.conf as a
> configuration mechanism is a bit on the lame side, and this is
> something we're aiming to fix in the near future. Thus, it's less of
> an issue.
>
>
>> Although since `pkgchk` still complains when they do get edited, I'm not
>> quite sure what "e" actually tells the software subsystem.
>>
>
> Not as much as it should. ;-}
>
Yeah, editable files are actually, IMO, rather pointless.
>
>> Anyways, sometimes you have to edit those /kernel/drv/*.conf files,
>> especially for fiber channel controllers! That's alright; that's what
>> they're there for.
>> Personally I would not manually go and hack away at a .conf file, but roll
>> out a modified package, but that's me, I don't do anything ad-hoc.
>>
>
> There are clearly better ways to manage this, which is why (in
> general) we're driving away from those files.
>
Actually, I'd just prefer to remove the .conf file altogether. The only
reason it is put on the system is for documentation, and quite frankly,
folks should be using ndd instead. (Until ndd is replaced by Brussels.)
I could just not deliver the .conf file at all, if that is preferable.
>
>>>> Third thing to consider is parametrizing. Instead
>>>>
>>> of setting "root sys" explicitly in the prototype
>>> file, consider defining something like
>>>
>>> Please don't. It'll break the packaging consistency
>>> checks.
>>>
>> That's really a shame, since one loses all teh advantages of
>> parametrization. No chance of adapting the checks?
>>
>
> Sure ... if you want to roll that into the wad as well.
>
> I certainly wouldn't recommend it. It seems like a lot of effort (and
> added text) for pretty much zero gain. (And perhaps some net loss in
> clarity.)
>
>
Agreed. I'm not going down that road. This isn't the RTI to start
"breaking new ground". :-)
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
