Re: [gentoo-dev] Deprecate EAPIs 1 and 2?
On Sun, 02 Jan 2011 18:02:48 +0200 Petteri Räty wrote: > It's quite likely that if you are currently on a system with Portage > that does not understand EAPI 1 there's so many obstacles along the > upgrade path that a clean install makes more sense. Maybe someone is > willing to test this so that we actually know if there is an upgrade > path from EAPI 0 available any more. One recent example is [1] (which the reporter ended up closing as WONTFIX himself). In that particular case, $someone could roll out newer stages based on the current tree. I think he just gave up, which is a bit of a pity. jer [1] https://bugs.gentoo.org/show_bug.cgi?id=346621
[gentoo-dev] Can a bash script source ebuild functions?
Hi, I would like to adapt my script that I run in the post install section inside an ebuild, to source some functions like elog and such. Is it possible? Regards, Kfir
[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..."
Re: [gentoo-dev] Can a bash script source ebuild functions?
On 01/03/2011 04:38 PM, Kfir Lavi wrote: > Hi, > I would like to adapt my script that I run in the post install section > inside an ebuild, to source some functions like elog and such. > > Is it possible? > > Regards, > Kfir I don't know about elog, but you can get einfo with: #!/bin/bash . /etc/init.d/functions.sh einfo "foobar"
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
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 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] Can a bash script source ebuild functions?
On Mon, Jan 3, 2011 at 4:46 PM, Samuli Suominen wrote: > On 01/03/2011 04:38 PM, Kfir Lavi wrote: > > Hi, > > I would like to adapt my script that I run in the post install section > > inside an ebuild, to source some functions like elog and such. > > > > Is it possible? > > > > Regards, > > Kfir > > I don't know about elog, but you can get einfo with: > > #!/bin/bash > > . /etc/init.d/functions.sh > > einfo "foobar" > > Yep, thanks. Kfir
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() ?
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 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() ?
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 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 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 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] Deprecate EAPIs 0 and 1?
On 16:46 Fri 31 Dec , "Paweł Hajdan, Jr." wrote: > On 12/31/10 12:13 PM, Petteri Räty wrote: > > EAPI 0 might stick around for quite a while but for example deprecating > > EAPI 1 shouldn't be as hard. > > That seems also to be a safe first step. EAPI-1 ebuilds were at least > written with EAPIs in mind. That's obviously not true for EAPI-0. > > We could even deprecate EAPI-2 in favor of EAPI-3, hmmm > > I think a repoman non-fatal warning would be fine. If we have a warning > about forcing -j1, we can surely have one about ancient EAPIs. I'm in favor of documenting things such that the latest EAPI is the standard and others are backwards diffs based on it, shifted to appendices or somewhere out of the way. This will encourage people to easily use the latest developments rather than trying to build up a mental stack of added and removed features across multiple levels. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpoajUBHwB8n.pgp Description: PGP signature
