> On 07/26/10 09:32 AM, Peter Memishian wrote: > > > > > Seeing yet another involvement of /etc/ > symlinks brought by Darren leads > > > me to question the architectural value of the > proposed changes. > > > I like cleanlyness. I also like > compatibility. This seems architecturally > > > to me like change for changes sake. Bigger > tail fins on this years car. > > > > > > What is the compelling reason for making an > incompatible change? > > > > > > -1 > > > > Though I'm not a voting member, I strongly agree. > > > > This proposed change solves no architecural problem > with the system that I > > can find (the directory is aptly named "/etc", > though our use of it has > > become more refined with time). However, it may > well require customers to > > retrain fingers and update scripts that have worked > for decades. If even > > one customer is inconvenienced by these changes, > I'd argue the cost has > > already exceeded the benefit. Yes, we can break > things, but that doesn't > > mean we should do so frivolously. > > I was inclined to agree that this change seemed > gratuitous. But then I > looked at /etc and discovered that the cleanup value > is larger than I > would have guessed - this case would remove fully 20% > of the entries in > /etc on my system. > > I think it's significant that we moved all of these > programs out of /etc > years ago, leaving behind the symlinks to help ease > the transition. > Because we haven't been adding new administrative > commands to /etc, I'm > willing to believe that administrators have updated > their PATH long ago > to replace /etc with /usr/sbin. [1] > > So while I agree with Meem's notion of avoiding > frivolous change, I > think this one is worth it. Of course, as others have > already pointed out: > > * /etc/rmt needs to stay because it's part of an > external protocol. > > * The PATH setting in /etc/skel files needs to have > /etc (and /usr/ucb) > removed and /usr/sbin added (perhaps /sbin too). > > * Any existing invocations of these commands in > Solaris (not just ON) > need to be fixed. > > Scott
Does anyone know/remember to what degree various pathname compatibility (including that in question) was driven by SunOS 4.x binary compatibility? If that's relevant, then either it should be left unbroken, or it should be formally gotten rid of. -- This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
