Quoting PMS, Chapter 8:

"All ebuild-defined variables discussed in this chapter must be defined
independently of any system, profile or tree dependent data, and must
not vary depending upon the ebuild phase."

http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD



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`
}

In $PORTDIR/sys-fs/udisks-glue/udisks-glue-1.2.0.ebuild to get S=
defined as:

fernandotcl-udisks-glue-f9b4839

Where "f9b4839" changes...


Far as I know, S= isn't used to generate metadata cache, so it's PMS
that need fixing for it's wording:

"All ebuild-defined variables used to generate metadata cache, discussed
in this chapter..."

On Mon, Jan 03, 2011 at 04:40:57PM +0200, Samuli Suominen wrote:
> Quoting PMS, Chapter 8:
>
> "All ebuild-defined variables discussed in this chapter must be defined
> independently of any system, profile or tree dependent data, and must
> not vary depending upon the ebuild phase."
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
>
> 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`
> }
>
> In $PORTDIR/sys-fs/udisks-glue/udisks-glue-1.2.0.ebuild to get S=
> defined as:
>
> fernandotcl-udisks-glue-f9b4839
>
> Where "f9b4839" changes...
>
>
> Far as I know, S= isn't used to generate metadata cache, so it's PMS
> that need fixing for it's wording:
>
> "All ebuild-defined variables used to generate metadata cache, discussed
> in this chapter..."

Yes, please

I've used that method to work around some github-tarballed packages
as well, seems to work pretty well.

Thanks,
--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

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?

Cheers,
Thomas

--
Thomas Kahle
http://dev.gentoo.org/~tomka/

On 01/03/2011 04:40 PM, Samuli Suominen wrote:
> Quoting PMS, Chapter 8:
>
> "All ebuild-defined variables discussed in this chapter must be defined
> independently of any system, profile or tree dependent data, and must
> not vary depending upon the ebuild phase."
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
>
>
>
> 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`
> }
>

This code could be simplified as:
S=*-${PN}-*

$ mkdir foo-1.2.3
$ PN=foo
$ S=foo-*
$ echo $S
foo-1.2.3

>
>
> Far as I know, S= isn't used to generate metadata cache, so it's PMS
> that need fixing for it's wording:
>
> "All ebuild-defined variables used to generate metadata cache, discussed
> in this chapter..."
>

It can be done retroactively if Portage has always worked with S being
defined inside phases and if that doesn't work then it can always be
part of EAPI 5. I opened a bug to track the request:

https://bugs.gentoo.org/show_bug.cgi?id=350478

Regards,
Petteri

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

Am 03.01.2011 15:40, schrieb Samuli Suominen:
> Quoting PMS, Chapter 8:
>
> "All ebuild-defined variables discussed in this chapter must be defined
> independently of any system, profile or tree dependent data, and must
> not vary depending upon the ebuild phase."
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
>
>
>
> 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`
> }
>
> In $PORTDIR/sys-fs/udisks-glue/udisks-glue-1.2.0.ebuild to get S=
> defined as:
>
> fernandotcl-udisks-glue-f9b4839
>
> Where "f9b4839" changes...
>
>
> Far as I know, S= isn't used to generate metadata cache, so it's PMS
> that need fixing for it's wording:
>
> "All ebuild-defined variables used to generate metadata cache, discussed
> in this chapter..."
>
>
>

i used another workaround for github based packages:

src_unpack() {
unpack ${A}
mv *-${PN}-* "${S}"
}

This saves a line and does not require the redefinition of S inside the function.


--
Thomas Sachau

Gentoo Linux Developer

On 01/03/2011 08:16 PM, Thomas Sachau wrote:
> Am 03.01.2011 15:40, schrieb Samuli Suominen:
>> Quoting PMS, Chapter 8:
>>
>> "All ebuild-defined variables discussed in this chapter must be defined
>> independently of any system, profile or tree dependent data, and must
>> not vary depending upon the ebuild phase."
>>
>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
>>
>>
>>
>> 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`
>> }
>>
>> In $PORTDIR/sys-fs/udisks-glue/udisks-glue-1.2.0.ebuild to get S=
>> defined as:
>>
>> fernandotcl-udisks-glue-f9b4839
>>
> i used another workaround for github based packages:
>
> src_unpack() {
> unpack ${A}
> mv *-${PN}-* "${S}"
> }
>
> This saves a line and does not require the redefinition of S inside the function.

Indeed. I've changed udisks-glue ebuild to use this.

On Mon, 03 Jan 2011 16:40:57 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> Quoting PMS, Chapter 8:
>
> "All ebuild-defined variables discussed in this chapter must be
> defined independently of any system, profile or tree dependent data,
> and must not vary depending upon the ebuild phase."
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
>
>
>
> 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 been doing that in www-client/opera for ages, having got fed up
with the varying packaging conventions used upstream:

src_unpack() {
unpack ${A}
if [[ ! -d ${S} ]]; then
cd "${WORKDIR}"/${PN}* || die "failed to enter work directory"
S="$(pwd)"
einfo "Setting WORKDIR to ${S}"
fi
}

I've never had complaints.

> Far as I know, S= isn't used to generate metadata cache, so it's PMS
> that need fixing for it's wording:
>
> "All ebuild-defined variables used to generate metadata cache,
> discussed in this chapter..."

As far as I can tell, the chapter does not mention S, but it could be
more specific. Don't see why it should, though.


jer

On 01/03/2011 09:31 PM, Jeroen Roovers wrote:
> On Mon, 03 Jan 2011 16:40:57 +0200
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> Quoting PMS, Chapter 8:
>>
>> "All ebuild-defined variables discussed in this chapter must be
>> defined independently of any system, profile or tree dependent data,
>> and must not vary depending upon the ebuild phase."
>>
>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob_plain;f=ebuild-vars.tex;hb=HEAD
>>
>>
>>
>> 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`
>> }
>> Far as I know, S= isn't used to generate metadata cache, so it's PMS
>> that need fixing for it's wording:
>>
>> "All ebuild-defined variables used to generate metadata cache,
>> discussed in this chapter..."
>
> As far as I can tell, the chapter does not mention S, but it could be
> more specific. Don't see why it should, though.

It's there.

Chapter 8.3.: Optional Ebuild Defined Variables. It's the last one in
the list.

On Mon, 03 Jan 2011 21:37:45 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> > As far as I can tell, the chapter does not mention S, but it could
> > be more specific. Don't see why it should, though.

> Chapter 8.3.: Optional Ebuild Defined Variables. It's the last one in
> the list.

Missed that. Thanks for pointing it out.


jer