The attached ebuild installs bitkeeper-3.0. It is a re-write of the ebuild in bug 7922 (bitkeeper-2.1); I think this implementation is marginally nicer. This is my first ebuild, so someone more knowledgeable should look over my code. In particular I'm not sure what the official way to select different package tarballs based on architecture is, or whether an /etc/env.d file should be created with a here-document in the ebuild or included as a separate file.
Created attachment 5550 [details] ebuild for BitKeeper 3.0
I will look at this and put it in portage asap.
*** Bug 7922 has been marked as a duplicate of this bug. ***
Update DEPEND, add BKL to licenses, and *poof* bitkeeper is now in dev-util. Enjoy.
I just noticed the bitkeeper-3.0 ebuild doesn't fix the permissions and ownership of the installed files after they come out of the tarball. Several files were world writable and all had a bizzare UID and GID. So, I'm including an appropriate patch, and a suggested patch for the ChangeLog. I guess this makes it bitkeeper-3.0-r1.ebuild. Can't believe I missed this.
Created attachment 5782 [details, diff] patch 3.0 -> 3.0-r1 Patch to fix the permissions and ownership of the installed files. Also changes the "use arch" constructs to look more like the form suggested in the Gentoo devel guide.
Created attachment 5783 [details, diff] suggested ChangeLog patch 3.0 -> 3.0-r1 Suggested ChangeLog patch for the ebuild patch
Instead of using chmod, did you try adding -p to the tar command? This will extract whatever permissions are in the archive and is probably the Right Thing To Do in this case. I have applied the use flag patch, but I will wait to hear back from you before I commit the -r1 ebuild.
Yeah, I thought of that myself. Unfortunately the permissions and ownerships encoded inside the tarball actually are wrong. On inspection, the bk install script does an equivalent operation after extracting the tarball. Don't know why I didn't see that the first time.
okay then, I've commited your changes as you submitted them.