I agree regarding an aversion to basing an ebuild off a VCS commit. My motive is to tag this ebuild as an outlier that eventually needs to change back, rather than to justify the practice in general.
For this particular package, I fear things will get more confusing before they get clearer. They've adopted a practice of committing features in the kernel, but allowing the userland tools to implement these features to remain spread out across several independent user/developer git repos. For the time being, basing the package off git will facilitate assembling the disparate pieces until the project settles down. On a side note, I prefer this method of identifying a specific commit and assigning a discrete release number to the practice of making -9999 packages. On Wed, Jan 18, 2012 at 11:14 AM, Ian Whyman <v00...@v00d00.net> wrote: > I generally advise against using got for this kind of thing. It is not the > recommend way to handle this scenario, you should create a snapshot ebuild > using a source checkout tarball [1] > > 1. > http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html > > On 18 January 2012 16:51, Mitch Harder <mitch.har...@sabayonlinux.org> > wrote: >> I've commited an updated ebuild for sys-fs/btrfs-progs-0.19_p111201 >> based on a discrete commit (using the EGIT_COMMIT="..." variable) from >> the upstream git repository at >> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git >> >> I wanted to document to the Sabayon development team why I've moved to >> a git based ebuild so you'll understand why it's there and when it >> makes sense to change back. >> >> First off, the movement towards an official 0.20 release is moving at >> a glacial pace. But there are many very important updates that have >> been published to the git repositories in the mean time. >> >> In the latest version, I've included the first generation of recovery >> tools to assist users in retrieving data from btrfs partitions that >> have been corrupted. Although a read/write btrfsck that can fix >> corruptions is not yet available, this is an important interim tool >> (I've heard it quipped that mkfs is the fsck for btrfs :) ) >> >> Also, since the hacking of the kernel.org servers in August/September >> of 2011, the official btrfs-progs-0.19 sources are no longer >> available. The sources are widely available on mirrors and in other >> distro's repositories, so that is only of minor relevance. >> >> As progress slowly moves towards the 0.20 version, I anticipate an >> extended period where all the update work will be scattered across >> various git repositories. So it will facilitate us in keeping up with >> updated features to structure the btrfs-progs ebuild from git sources >> until development settles down to a discrete release schedule. >> > > -- > Ian Whyman > v00d00.net > > > >
