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

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.

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?

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.

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.

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.

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".

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:

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.

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:

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.)_________________elogind(elogind) - [TRACKER] sys-auth/elogind - Integration into Gentoo
"A conservative is a man who is too cowardly to fight and too fat to run."
-- Elbert Hubbard

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:

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"