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
pgpjgOC9MSjIh.pgp
Description: PGP signature
