1.5.77 port of openafs

[Benjamin Kaduk]

On Tue, 21 Sep 2010, Jan Henrik Sylvester wrote:

> I wanted to give 1.5.77 a try after seeing some FreeBSD related improvements 
> in the changelog.
>
> Is http://web.mit.edu/freebsd/openafs/openafs.shar the working version of 
> something that might end up in ports or do you have another one in progress? 
> (I assume that the git version is not mend for ports.)

Oops, I started to make an updated sharball but didn't get around to 
testing it.
I think it was at
http://web.mit.edu/freebsd/openafs/tmp/openafs.shar (off the top of my 
head), but it wouldn't have the plist or package fixes that you describe 
below.


>
> Since http://web.mit.edu/freebsd/openafs/openafs.shar is still at 1.5.75, I 
> started updating it.
>
> To get it to compile, I removed two patches that do not apply to 1.5.77 
> anymore, after updating the version and distinfo.
>

Those patches (or something equivalent to them) have been merged into 
upstream.

> Verifying the pkg-plist, I realized that 'pkg_create -b' does not produce a 
> clean package (giving the same files as the port that can cleanly be 
> removed): Besides some files missing in pkg-plist, lib/openafs is eventually 
> emtpy and missing from the package and ThisCell.sample contains the sample 
> line twice when installed from the package. Moreover, whether afsd.fuse is 
> installed or not depends on the presence of the fuse-libs port.
>
> I have attached an updated version of the port that fixes issues I found 
> related to packaging. I tried to make the diff to the old version 
> minimalistic by not doing anything like sorting the pkg-plist.
>
> Does it look ok?
>

Well, I'm still at work, so I can't test or look too closely, but it seems 
pretty reasonable.  (I think that the et_lex.lex.l patch is not needed 
anymore, but don't remember the details of what fix made it where 
offhand.)
Thanks for putting the work in to do the updates and testing!


> I hope I verified all correctly:
> - 'pkg_create -b' produces a package that installs the same files as the 
> port.
> - The port or package can be removed cleanly WITH_FUSE or without, with 
> modified configuration files present or without.
> - The binaries seem to link to the same files in a clean environment and in a 
> polluted one (1155 packages installed, including fuse-libs).
>

Excellent.  Have you also followed the steps here?
http://www.freebsd.org/doc/en/books/porters-handbook/porting-testing.html
(The porter's handbook is a pretty nice resource for ports tips, though it 
sadly doesn't give much guidance for how to deal with kernel modules.)

> All testing was on 8.1-RELEASE.
>
> As for functionality: I did a little bit of copying from and to AFS and using 
> basic fs and pts commands. I did not experience any problems. I have yet to 
> test the issues that I had with 1.5.75 (copying files larger than the cache 
> size, unmounting the AFS, stopping the afsd, ...).

Okay.  As I noted in the tmp/openafs.shar README, I think this code has 
survived a buildworld in AFS, but deadlocks on a parallel make.
(Actually most of the cycles in the past couple weeks that I would have 
put into openafs were devoted to fixing FreeBSD's ar(1) to not die when 
presented with a file owned by a machine principal in AFS, but I think I 
have a working patch for that.)

>
> Possible improvements before it goes to ports: Nicer error for emtpy 
> /usr/src/ or /usr/obj/, creation of /afs, creation of a sample for 
> /usr/local/etc/cacheinfo, sorting pkg-plist. Before I start anything in that 
> direction:
>
> Are you planing to bring something to ports anytime soon -- maybe as 
> net/openafs-devel -- or is it still too early?

I hadn't thought too hard about when to bring something into ports, but I 
do think the code is reaching a point where it is actually useful to 
non-developers.  In my dream world, we would figure out the locking issues 
that cause parallel make to deadlock in time for a 1.6 release, and that 
would go into ports, but I think that fixing up your packaging of 1.5.77 
and making it net/openafs-devel would be a reasonable thing to do.

Thanks again for moving this forward,

Ben