OpenAFS port

Derrick Brashear shadow at
Sat Dec 13 07:24:40 PST 2008

I don't believe there are conflicts between client objects, and server
objects. An independent client and server port should be possible.

But if not, why a metaport and not say openafs-base that both client and
server depend on?

On Sat, Dec 13, 2008 at 8:19 AM, Boris Samorodov <bsam at> wrote:

> Palle Girgensohn <girgen at> writes:
> > 13 dec 2008 kl. 03.27 skrev "Tony Jago" <tony at>:
> >
> >> I think that we probably don't need more then one port. Yes, I know
> >> I was the one what originally proposed the meta port but I have
> >> changed my mind :) The reason we had a server and a client port
> >> originally was that the server was the only bit working and the
> >> kernel model was set not to compile. The client was was arla client.
> >> Now that both the openafs server and client are supported by the
> >> openafs team I can see no reason why it shouldn't be all in one
> >> port. The port should have separate rc variable to allow the
> >> administrator to only start the client or the server if they choose
> >> to. openafs_client_enable="YES" and openafs_server_enable="YES" for
> >> example. This gets around all the conflicting file problems. The
> >> kernel module need only be loaded if the client is required. This
> >> would seem to be a much easier and cleaner solution.
> >
> > As long as nothing conflicts with arla, I also suggest an all in one
> > installation. Keeps it simple, which is always important.
> I'd vote for that myself if and only if we speak about a ports
> subsystem. But there are packages as well. And for those who prefer
> using packages I'd rather give an opportunity.
> Said that I propose following ports:
> . net/openafs (server+client)
> . net/openafs-server;
> . net/openafs-client.
> One of them will be a master port (I don't figure out which one,
> but that will be either openafs or openafs-server). All of them
> will conflict each other, i.e. only one of them can be installed
> at a machine.
> That way we may give all users their chance.
> Opinions? Thanks!
> --
> Boris Samorodov (bsam)
> Research Engineer, Telephone & Internet SP
> FreeBSD committer, The Power To Serve


More information about the freebsd-afs mailing list