Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Tue, 04 Jan 2011 10:51:06 +0200 Samuli Suominen wrote: > To fix the eclasses, and several ebuilds in tree to not do this for > something that "might be a problem" or fix the PMS wording to match > reality? Reality is that what you're doing has been problematic, which is why PMS contains the wording that it does. That you happen to have gotten away with it in a particular case is not grounds for amending the specification to incorrectly claim that the general case will work. You may find it helpful to investigate exactly what "reality" is. As is often the case, "reality" is not "what you want it to be". If you really want PMS changed, you'll need to produce a list of specific behaviours that have consistently been safe. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On 01/04/2011 10:22 AM, Ciaran McCreesh wrote:
> On Mon, 03 Jan 2011 16:40:57 +0200
> Samuli Suominen wrote:
>> 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..."
>
> There's also:
>
> Global variables must only contain invariant values
> (see~\ref{sec:metadata-invariance}). If a global variable's value is
> invariant, it may have the value that would be generated at any
> given point in the build sequence.
>
> which is true for all global variables, not just for metadata ones.
> That paragraph's there because historically global variables have done
> various different things (being re-evaluated for every phase, or just
> some phases, or never, or when loaded from VDB, or ...).
>
I don't know the code involving package managers here, but we have
eclasses like qt4-r2.eclass and kde4-meta.eclass redefining S= from
src_unpack() and I haven't seen a single bug report about it.
To fix the eclasses, and several ebuilds in tree to not do this for
something that "might be a problem" or fix the PMS wording to match reality?
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Mon, 03 Jan 2011 16:40:57 +0200
Samuli Suominen wrote:
> 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..."
There's also:
Global variables must only contain invariant values
(see~\ref{sec:metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any
given point in the build sequence.
which is true for all global variables, not just for metadata ones.
That paragraph's there because historically global variables have done
various different things (being re-evaluated for every phase, or just
some phases, or never, or when loaded from VDB, or ...).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Mon, 03 Jan 2011 19:16:13 +0100
Thomas Sachau wrote:
> src_unpack() {
> unpack ${A}
> mv *-${PN}-* "${S}"
> }
>
> This saves a line and does not require the redefinition of S inside
> the function.
It should probably die() though. I've looked at opera tarballs again,
and in fact they are still varying the directory based on both the OS
and the arch.
The "x86-fbsd" tarball has "opera-11.00-1156.i386.freebsd" whereas plain
"x86" is brought to users as "opera-11.00-1156.i386.linux". This isn't
the reason why I started modifying S based on what had been unpacked,
though - it was becomes sometimes I'd see "opera_11.00-1156.i386.linux"
instead of "opera-11.00-1156.i386.linux" too, and other punctuational
flux.
Anyway, I've gone now from many lines to a single extra line in
src_unpack():
--- opera-11.00.1156.ebuild 22 Dec 2010 16:14:34 - 1.3
+++ opera-11.00.1156.ebuild 3 Jan 2011 20:06:25 - 1.5
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
+ mv -v * "${S}" || die
}
src_prepare() {
That sure helped.
jer
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Mon, 03 Jan 2011 21:37:45 +0200 Samuli Suominen 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
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On 01/03/2011 09:31 PM, Jeroen Roovers wrote:
> On Mon, 03 Jan 2011 16:40:57 +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`
>> }
>> 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.
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
On Mon, 03 Jan 2011 16:40:57 +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`
> }
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
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
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.
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
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
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
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
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
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/
pgpp51NeteucW.pgp
Description: PGP signature
Re: [gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
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
pgpGzstSRPxR3.pgp
Description: PGP signature
[gentoo-dev] Defining S= from ebuild phase, src_unpack() ?
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..."
