> UNIX admin writes: > > In "new/usr/src/pkgdefs/SUNWdmfe/prototype_com", > I'd set: > > > > d none kernel/drv/amd64 ? ? ? > > ... > > d none kernel/drv/sparcv9 ? ? ? > > For unbundled items (stuff that ships separately from > an OpenSolaris > distribution), that's good advice. > > 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? 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. > > 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". Although since `pkgchk` still complains when they do get edited, I'm not quite sure what "e" actually tells the software subsystem. 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. > > 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? This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
