View previous topic :: View next topic |
Author |
Message |
mahnmut n00b
Joined: 13 Nov 2012 Posts: 16
|
Posted: Wed Sep 18, 2013 7:39 pm Post subject: unpack an other package in ebuild ? |
|
|
Hi all,
I actually working on ebuild to simplify my installation on different computer but I have a problem with one package using source from an other program.
So to start and it's working fine I do that :
Code: | # Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sci-biology/oases/oases-0.2.08,v 1.5 2011/12/21 09:02:55 phajdan.jr Exp $
EAPI=4
inherit eutils toolchain-funcs flag-o-matic
MY_P=${PN}_${PV}
DESCRIPTION="Oases is a de novo transcriptome assembler designed to produce transcripts from short read"
HOMEPAGE="http://www.ebi.ac.uk/~zerbino/oases/"
SRC_URI="http://www.ebi.ac.uk/~zerbino/oases/${MY_P}.tgz"
# Modification due to a difference in version number : 0.2.08 & 0.2.8
MY_P=${PN}_0.2.8
LICENSE="GPL-2"
SLOT="0"
IUSE="-doc"
KEYWORDS="amd64 x86"
RDEPEND=">=sci-biology/velvet-1.2.08"
DEPEND="${RDEPEND}
doc? ( virtual/latex-base )"
S="${WORKDIR}"/${MY_P}
src_prepare() {
# necessary?
# append-flags -O3 # as recommended by upstream
use doc || sed -i -e '/default :/ s/doc//' "${S}"/Makefile || die
# oases use velvet src to compile
velvetver=$(cd /var/db/pkg/sci-biology/ && ls -d * | grep velvet | cut -d- -f2)
tar xvf /usr/portage/distfiles/velvet_$velvetver.tgz -C ../
}
src_compile() {
tc-export CC
MAKE_XOPTS="VELVET_DIR=../velvet_$velvetver"
if [[ $VELVET_MAXKMERLENGTH != "" ]]; then MAKE_XOPTS="$MAKE_XOPTS MAXKMERLENGTH=$VELVET_MAXKMERLENGTH"; fi
if [[ $VELVET_CATEGORIES != "" ]]; then MAKE_XOPTS="$MAKE_XOPTS CATEGORIES=$VELVET_CATEGORIES"; fi
emake -j1 $MAKE_XOPTS || die
emake -j1 $MAKE_XOPTS color || die
}
src_install() {
dobin oases oases_de || die
insinto /usr/share/${PN}
# doins -r contrib || die
# dodoc Manual.pdf || die
}
pkg_postinst() {
elog "To adjust the MAXKMERLENGTH or CATEGORIES parameters as described in the manual,"
elog "please set the variables VELVET_MAXKMERLENGTH or VELVET_CATEGORIES in your"
elog "environment or /etc/make.conf, then re-emerge velvet and this package. For example:"
elog " VELVET_MAXKMERLENGTH=NN emerge [options] velvet"
} |
(I based it on the velvet-1.0.18.ebuid so ... )
It work fine but i read than it's BAD to use tar in an ebuild so i try with unpack like that :
Code: | unpack velvet_${velvetver}.tgz
and that
MAKE_XOPTS="VELVET_DIR=../../../velvet-$velvetver/work/velvet_$velvetver"
|
In first, he unpack it in the oases directory
and secondly he tell me this : velvet_1.2.10.tgz does not exist
But :
Code: | ls /usr/portage/distfiles/ |grep velvet
velvet_1.0.18.tgz
velvet_1.2.10.tgz
|
(of course I previously make the ebuild for velvet'1.2.10)
If someone can help to make a clean ebuild.
Thanks
Last edited by mahnmut on Fri Dec 20, 2013 4:56 pm; edited 1 time in total |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21624
|
Posted: Wed Sep 18, 2013 10:09 pm Post subject: Re: unpack an other package in ebuild |
|
|
mahnmut wrote: |
I actually working on ebuild to simplify my installation on different computer but I have a problem with one package using source from an other program.
| Generally, you should not do this. Instead, you should have a single ebuild which builds the program with its addons. If you only need headers and libraries from the main program, then you can do a separate build.
mahnmut wrote: | Code: |
# append-flags -O3 # as recommended by upstream
|
| This is probably bad advice. Gentoo recommends against -O3.
mahnmut wrote: | Code: |
velvetver=$(cd /var/db/pkg/sci-biology/ && ls -d * | grep velvet | cut -d- -f2)
tar xvf /usr/portage/distfiles/velvet_$velvetver.tgz -C ../
|
| There is no guarantee that searching that directory will find what you intend to find, nor that the source file will be present on the system. If you must have source from the other program, you should add that source to your SRC_URI so that Portage will make it available.
mahnmut wrote: | Code: |
emake -j1 $MAKE_XOPTS || die
emake -j1 $MAKE_XOPTS color || die
|
| Are these -j1 needed? If so, what bug reports describe their necessity? |
|
Back to top |
|
|
mahnmut n00b
Joined: 13 Nov 2012 Posts: 16
|
Posted: Thu Sep 19, 2013 6:41 am Post subject: Re: unpack an other package in ebuild |
|
|
Hu wrote: | Generally, you should not do this. Instead, you should have a single ebuild which builds the program with its addons. If you only need headers and libraries from the main program, then you can do a separate build. |
Yes i know, i have an ebuild only for velvet-1.2.10 but oases need source of velvet
like said in oases manual :
Code: | If the Velvet source directory is not next to the Oases directory, or if it
has a different name, you must indicate the location of this directory:
make ’VELVET_DIR=/path/to/velvet’
|
For the other things you tel me, it's just a copy of the velvet ebuild found in portage but i correct em in the oases ebuild and in my velvet ebuild too. |
|
Back to top |
|
|
mahnmut n00b
Joined: 13 Nov 2012 Posts: 16
|
Posted: Thu Sep 19, 2013 9:59 am Post subject: |
|
|
So yes the emake -j1 is needed for velvet but not sur for oases
I change the SRC_URI to this :
Code: | SRC_URI="http://www.ebi.ac.uk/~zerbino/oases/${MY_P}.tgz
http://www.ebi.ac.uk/~zerbino/velvet/velvet_$velvetver.tgz"
|
But i need to use the velvetver variable to be sur that velvet version is the same as installed. (RDEPEND=">=sci-biology/velvet-1.2.08")
Code: | velvetver=$(cd /var/db/pkg/sci-biology/ && ls -d * | grep velvet | cut -d- -f2) |
of course during digest I have a warning :
Code: | * QA Notice: 'grep' called in global scope: sci-biology/oases-0.2.08 |
but the probleme still the same :
Code: | Unpacking velvet_1.2.10.tgz to /var/tmp/portage/sci-biology/oases-0.2.08/work/oases_0.2.8 |
I would like to have a line like this :
Code: | Unpacking velvet_1.2.10.tgz to /var/tmp/portage/sci-biology/velvet-1.2.10/work/velvet_1.2.10 |
or this :
Code: | Unpacking velvet_1.2.10.tgz to /var/tmp/portage/sci-biology/oases-0.2.08/work/velvet_1.2.10 |
i try to temporary change the $A variable like this Code: | A="${WORKDIR}"/velvet-$velvetver | but no change durring unpacking |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21624
|
Posted: Thu Sep 19, 2013 10:17 pm Post subject: |
|
|
Do not examine the installed package database. Instead, pick a specific version of velvet and use it. You could also choose to make this a modification of the velvet ebuild, rather than a separate ebuild in its own right. That seems like a better fit since the two upstream projects are so closely integrated. |
|
Back to top |
|
|
mahnmut n00b
Joined: 13 Nov 2012 Posts: 16
|
Posted: Fri Sep 20, 2013 2:13 pm Post subject: |
|
|
Yes but velvet and oases are two different application from two different package.
Velvet don't need oases and oases don't need velvet (only his source).
I force it to depend on velvet only to be sure that the latest is install.
When you said :
Hu wrote: | You could also choose to make this a modification of the velvet ebuild, rather than a separate ebuild in its own right.t |
The problem stile the same. Who to extract two archive in two different location in the same ebuild without using tar.
And thanks for your reply. |
|
Back to top |
|
|
mahnmut n00b
Joined: 13 Nov 2012 Posts: 16
|
Posted: Fri Dec 20, 2013 4:58 pm Post subject: |
|
|
Any new idea ? |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21624
|
Posted: Fri Dec 20, 2013 11:56 pm Post subject: |
|
|
You might consider them to be separate packages, but if Oases cannot build without internal headers from Velvet, then in my opinion, they are closely integrated and must be built together by a single ebuild. If Oases can be built using only headers and libraries installed by Velvet, then there is no problem with treating this as a normal ebuild. If you did not have the requirement that Oases be installed along with the exact version that provided the internal headers, then this would be easier. |
|
Back to top |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2284 Location: Adendorf, Germany
|
Posted: Sat Dec 21, 2013 10:13 am Post subject: |
|
|
Another idea:
As velvet is in the portage tree, but as version 1.0.18, you could post an updated ebuild for the new version at bugs.gentoo.org for a version bump.
The idea behind that: Add a USE flag to velvet that tells the ebuild to make the sourcees/headers required by your other package available.
And in the other ebuild simply depend on the newer velvet version and explicitly set "VELVET_DIR=/path/to/velvet".
Everything else would be bundling, and bundling is against gentoo philosophy. _________________ Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
Back to top |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2284 Location: Adendorf, Germany
|
Posted: Sat Dec 21, 2013 10:50 am Post subject: |
|
|
Forget my idea.
I just had a look at the oases Makefile, and it links to all of the velvet object files. This means, that although you can have an independent velvet ebuild and install, oases needs the full velvet tarball.
So the most easy way is to add the velvet source tarball to the SRC_URI of your oases ebuild and have it unpacked by emerge automatically.
in your portage workdir there will be another directory with velvet in it. You then must set VELVET_DIR to the emake command and the Makefile should do the rest for you.
Just a tip: Use the ebuild command to test and check the individual stages of the emerge process.
So consider your ebuild to be lying in /usr/local/portage/sci-biology/oases, do: Code: | ~ $ ebuild /usr/local/portage/sci-biology/oases/oases-0.2.08.ebuild unpack | Now you can check whether the tarballs are unpacked as intended. Code: | ~ $ ebuild /usr/local/portage/sci-biology/oases/oases-0.2.08.ebuild configure | Prepare and configure your build. Check that all options intended are set using 'configure'. Code: | ~ $ ebuild /usr/local/portage/sci-biology/oases/oases-0.2.08.ebuild compile
~ $ ebuild /usr/local/portage/sci-biology/oases/oases-0.2.08.ebuild install | These should be self explanatory. 'install' fills the 'image' directory of your portage work directory. Code: | ~ $ ebuild /usr/local/portage/sci-biology/oases/oases-0.2.08.ebuild merge | The last finishes the merge. _________________ Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
Back to top |
|
|
mahnmut n00b
Joined: 13 Nov 2012 Posts: 16
|
Posted: Mon Dec 23, 2013 8:04 am Post subject: |
|
|
Yamakuzure,
thanks, I already try to add the tar to the src_uri but probably don't correctly read the output or not check the tmp folder but in the
/var/tmp/portage/sci-biology/oases-0.2.08/work folder i have my 2 tarball extract in 2 différent folder.
So now i want to corect that bad practice.
QA Notice: 'grep' called in global scope: sci-biology/oases-0.2.08
Juste want to have the installed velvet version ?
I can, like Hu submit to me, force a specific version but i would like to have a generalistic ebuild to esealy update it later. |
|
Back to top |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2284 Location: Adendorf, Germany
|
Posted: Mon Dec 23, 2013 7:54 pm Post subject: |
|
|
mahnmut wrote: | Ythanks, I already try to add the tar to the src_uri but probably don't correctly read the output or not check the tmp folder but in the
/var/tmp/portage/sci-biology/oases-0.2.08/work folder i have my 2 tarball extract in 2 différent folder.
So now i want to corect that bad practice. | That is not bad practice, that is exactly how this works. It should look like this: Code: | /var/tmp/portage/sci-biology/oases-0.2.08/work/oases-0.2.08 # <-- The oases tarball unpacked
/var/tmp/portage/sci-biology/oases-0.2.08/work/velvet-1.2.10 # <-- The velvet tarball unpacked | If it looks like this, everything is fine and you just need to tell the oases build system where the velvet tarball is unpacked to. (VELVET_DIR="${S}/../velvet-1.2.10" might work.) _________________ Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
Back to top |
|
|
mahnmut n00b
Joined: 13 Nov 2012 Posts: 16
|
Posted: Thu Dec 26, 2013 9:53 am Post subject: |
|
|
Yamakuzure wrote: | mahnmut wrote: | Ythanks, I already try to add the tar to the src_uri but probably don't correctly read the output or not check the tmp folder but in the
/var/tmp/portage/sci-biology/oases-0.2.08/work folder i have my 2 tarball extract in 2 différent folder.
So now i want to corect that bad practice. | That is not bad practice, that is exactly how this works. It should look like this: Code: | /var/tmp/portage/sci-biology/oases-0.2.08/work/oases-0.2.08 # <-- The oases tarball unpacked
/var/tmp/portage/sci-biology/oases-0.2.08/work/velvet-1.2.10 # <-- The velvet tarball unpacked | If it looks like this, everything is fine and you just need to tell the oases build system where the velvet tarball is unpacked to. (VELVET_DIR="${S}/../velvet-1.2.10" might work.) |
Sorry, I did not well express myself, It's a Misunderstanding.
Yes for the tarball, this is exacly what I want and it's stupid that i don't see it before. I correct my ebuild after your message and it work exaclty like a want.
The bad practice i talk is an other "problem" : Code: | QA Notice: 'grep' called in global scope: sci-biology/oases-0.2.08 |
I do a grep to know what version of velvet is install like this : Code: | velvetver=$(cd /var/db/pkg/sci-biology/ && ls -d * | grep velvet | cut -d- -f2) |
But this can make trouble in some case.
Is there an other way in ebuild to know the installed apackage version ?
actualy my ebuild look like this :
Code: | # Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sci-biology/oases/oases-0.2.08,v 1.5 2013/09/19 09:02:55 mahn Exp $
# base on velvet ebuild by phajdan.jr
EAPI=4
inherit eutils toolchain-funcs flag-o-matic
velvetver=$(cd /var/db/pkg/sci-biology/ && ls -d * | grep velvet | cut -d- -f2)
MY_P=${PN}_${PV}
DESCRIPTION="Oases is a de novo transcriptome assembler designed to produce transcripts from short read"
HOMEPAGE="http://www.ebi.ac.uk/~zerbino/oases/"
SRC_URI="http://www.ebi.ac.uk/~zerbino/oases/${MY_P}.tgz
http://www.ebi.ac.uk/~zerbino/velvet/velvet_$velvetver.tgz"
MY_P=${PN}_0.2.8
LICENSE="GPL-2"
SLOT="0"
IUSE="-doc"
KEYWORDS="amd64 x86"
RDEPEND=">=sci-biology/velvet-1.2.08"
DEPEND="${RDEPEND}
doc? ( virtual/latex-base )"
S="${WORKDIR}"/${MY_P}
src_prepare() {
# necessary?
append-flags -O3 # as recommended by upstream
use doc || sed -i -e '/default :/ s/doc//' "${S}"/Makefile || die
}
src_compile() {
tc-export CC
MAKE_XOPTS="VELVET_DIR=../velvet_$velvetver"
if [[ $VELVET_MAXKMERLENGTH != "" ]]; then MAKE_XOPTS="$MAKE_XOPTS MAXKMERLENGTH=$VELVET_MAXKMERLENGTH"; fi
if [[ $VELVET_CATEGORIES != "" ]]; then MAKE_XOPTS="$MAKE_XOPTS CATEGORIES=$VELVET_CATEGORIES"; fi
emake -j1 $MAKE_XOPTS || die
}
src_install() {
dobin oases || die
insinto /usr/share/${PN}
# doins -r contrib || die
# dodoc Manual.pdf || die
}
pkg_postinst() {
elog "To adjust the MAXKMERLENGTH or CATEGORIES parameters as described in the manual,"
elog "please set the variables VELVET_MAXKMERLENGTH or VELVET_CATEGORIES in your"
elog "environment or /etc/make.conf, then re-emerge velvet and this package. For example:"
elog " VELVET_MAXKMERLENGTH=NN emerge [options] velvet"
elog "Oases need VELVET_MAXKMERLENGTH > 95"
}
|
|
|
Back to top |
|
|
|