[OpenAFS] Recommended way to start up OpenAFS on Solaris 10?

[Derrick Brashear]

On Jan 29, 2010, at 7:43 AM, Jeffrey Altman <jaltman@secure-endpoints.com 
 > wrote:

> On 1/29/2010 7:18 AM, David Boyes wrote:
>> On 1/29/10 6:31 AM, "Simon Wilkinson" <sxw@inf.ed.ac.uk> wrote:
>>
>>> Ultimately this is the key issue. Until it becomes a high priority  
>>> for
>>> someone, and that person publishes the necessary configuration,  
>>> this isn't
>>> going to improve. Equally critically, we need people to take  
>>> responsibility
>>> for maintaining the packaging as releases occur.
>>>
>>> Any volunteers?
>>
>> Got a few other things to do at the moment, but we should discuss  
>> this
>> off-list. There may be an opportunity to do something about this.
>
> Derrick and Doug Engert have been the Binary Release builders for
> Solaris.  (See the Port Masters / Binary Release Builders list
> at http://www.openafs.org/credits.html).  I suspect that if OpenAFS  
> were
> contributed scripts for constructing native installation packages that
> they would be willing to make use of them.
>
> If you would like to participate in release building, please add
> yourself to the release-team mailing list and participate in the
> release team Jabber meetings that occur prior to each release.
> https://lists.openafs.org/mailman/listinfo/release-team
>
> On 1/29/2010 7:12 AM, David Boyes wrote:
>> Meh. The Transarc paths are passably tolerable, no need to invent a  
>> wheel
>> for invention's sake. It'd be useful to see what others have done to
> see if
>> my assumptions are close to what others do. Anyone that would be
> willing to
>> let me look at what they've done would be appreciated -- no strings
>> attached.
>
> Transarc paths continue to be used in Solaris packaging for  
> consistency
> with prior releases.  We are conservative about changing the defaults
> in order to make upgrading for existing deployments easier.  This is
> not to say that changes cannot be made but we would prefer that there
> be either significant reasons for doing so or strong support from the
> community for the change.
>
or a migration path and an add-on compatibility package of symlinks to  
mitigate confusion for long-time users