Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?

[Brian Harring]

On Mon, Jan 03, 2011 at 04:15:01PM +0100, Thomas Kahle wrote:
> On 17:02 Mon 03 Jan     , Alex Alexander wrote:
> > On Mon, Jan 03, 2011 at 04:40:57PM +0200, Samuli Suominen wrote:
> > > Quoting PMS, Chapter 8:
> > >
> > > This is very inconvinent rule for example, github tarballs where the
> > > directory changes with every release. I've used this:
> > >
> > > src_unpack() {
> > > 	unpack ${A}
> > > 	cd *-${PN}-*
> > > 	S=`pwd`
> > > }
> > >
> > I've used that method to work around some github-tarballed packages
> > as well, seems to work pretty well.
>
> github ebuilds will continue to be a topic, would you consider a
> github.eclass useful at some point?

Just a quick brain dump, but the following (after someone validates it 
removing my typos) should work-

"""
S=foon-1.2
GITHUB_S="${S}-*"

github_src_unpack() {
  einfo "upstream needs a wedgie"
  if [ -n "${GITHUB_UNPACKER}" ]; then
     ${GITHUB_UNPACKER}
  else
     unpack ${A}
  fi
  # reset to workdir, on the offchange a custom unpacker dropped us
  # elsewhere.
  ( cd ${WORKDIR} && ln -s ${GITHUB_S} ${S}; )
  [ -e "${S}" ] || die "failed to symlink around github whackyness"
}
"""

As said, I likely typo'd something in there, but you get the idea.  
The GITHUB_UNPACKER bit allows you to point it at a different unpack 
function- that unpacker however will have to stay out of ${S} (should 
anyways, should be doing any mods from src_prepare). 

Step #2 is to go yell at upstream that a tagged release shouldn't 
have the sha1 rev slapped onto the directory name- that belongs in a 
file w/in the release.

Personally, I'm not much for having ${S} be non-constant- strikes me 
it'll allow for some odd bugs if eclasses store the value during inherit.

~harring