Gentoo Archives: gentoo-portage-dev

From: Marius Mauch <genone@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Custom eclass question
Date: Mon, 10 Oct 2005 01:22:32
Message-Id: 4349B693.9040805@gentoo.org
In Reply to: [gentoo-portage-dev] Custom eclass question by Mikey
1 Mikey wrote:
2 > The utility that fetches packages via emerge mangles the resulting file
3 > name, as well as wget (does emerge use wget?). When fetching the above url,
4 > emerge or wget saves the file as "package_ids.php?action=package&id=10105".
5 > This of course throws a wrench into my use of custom ebuilds :)
6
7 [snip]
8
9 > What I would like to do is create a custom elcass that allows me to replace
10 > the "standard" ebuild package fetching routines. It would need to:
11 >
12 > 1) Check that the source tarball does not already exist.
13 > 2) If the correct source tarball does not already exist, fetch it using
14 > something like wget -O source.tar.gz
15 > 3) Rename source.tar.gz to ${DISTDIR}/${PN}-${PV}.tar.gz
16 >
17 > My problem is that I cannot seem to locate where any package fetching
18 > routines are in any of the existing eclasses to use as a template. Another
19 > thing I am curious about, will custom eclasses in PORTDIR_OVERLAY work
20 > correctly (assuming they are written correctly).
21
22 Well, ebuilds (and therefore eclasses) can't override anything related
23 to the fetch process (other than setting RESTRICT and/or SRC_URI). Your
24 problem has to be fixed server side (assuming you want a proper
25 solution), as portage *needs* the correct filename in SRC_URI for things
26 like md5 verification. So even if $FETCHCOMMAND would save your file
27 with the "right" name you would be in trouble.
28
29 Marius
30 --
31 gentoo-portage-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-portage-dev] Custom eclass question Mikey <mikey@×××××××××××.com>