| 1 |
Mike Frysinger <vapier@g.o> wrote: |
| 2 |
> On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote: |
| 3 |
> > Currently, we pretty much leave out the big dogs of build depends from |
| 4 |
> > ebuilds- basically we rely on the profile to require a suitable |
| 5 |
> > toolchain. Couple of issues with this though- |
| 6 |
> |
| 7 |
> so what you're proposing is that we add binutils/gcc/glibc to every package |
| 8 |
> that compiles something |
| 9 |
|
| 10 |
Can you compile without binutils/gcc/glibc? No? Then you need it. |
| 11 |
|
| 12 |
> make to every package that uses make, |
| 13 |
|
| 14 |
Again, if you depend on make, then DEPEND on make. |
| 15 |
|
| 16 |
> sed/grep/bash/coreutils to every package which runs configure |
| 17 |
|
| 18 |
That's quite an interesting case. Yes, those should be in DEPEND, but it |
| 19 |
might be prudent to create an appropriate shortcut instead of explicitly |
| 20 |
adding each of those. |
| 21 |
|
| 22 |
Three possibilities come to mind. |
| 23 |
|
| 24 |
0) For ebuilds which use the standard GNU autoconf-generated configure |
| 25 |
script, a standard set of tools could be added to DEPEND from a |
| 26 |
standard variable. |
| 27 |
|
| 28 |
DEPEND="${ac-configure} dev-libs/libwombat app-misc/imanotherdep" |
| 29 |
|
| 30 |
where ${ac-configure} expands to everything that runs in yer typical |
| 31 |
configure script. |
| 32 |
|
| 33 |
1) Use the eclasses. Right before inheriting eutils, provide a token to |
| 34 |
tell eutils to add some appropriate DEPEND tokens. |
| 35 |
|
| 36 |
ac-configure=yup |
| 37 |
inherit eutils |
| 38 |
|
| 39 |
Many of the eclasses add a few DEPEND tokens. Use the standard |
| 40 |
eclass(es) to add the standard DEPENDs. |
| 41 |
|
| 42 |
2) Well, maybe cramming this into eutils isn't such a hot idea, but |
| 43 |
creating an eclass for the purpose of adding the generic dependencies |
| 44 |
would work better. |
| 45 |
|
| 46 |
edeps="configure make c-tools" |
| 47 |
inherit edeps |
| 48 |
|
| 49 |
> tar/gzip/bzip2 to every package which has a gzipped/bzipped tarball in |
| 50 |
> SRC_URI ? |
| 51 |
|
| 52 |
Now this could _definitely_ play into suggestion (2) above. Have the |
| 53 |
edeps eclass check the SRC_URI and add the appropriate unpacking |
| 54 |
packages. |
| 55 |
|
| 56 |
edeps="make" |
| 57 |
SRC_URI="http://www.wombats.com/i_need_tar_and_bzip2.tar.bz2" |
| 58 |
inherit edeps |
| 59 |
|
| 60 |
Whee. |
| 61 |
|
| 62 |
<rant class="flame"> |
| 63 |
I know this will be shot down, as it has been shot down each time in the |
| 64 |
past that somebody has suggested it. I wish it were not the case. Almost |
| 65 |
every ebuild in the tree fails to completely and accurately reflect its |
| 66 |
dependencies. The fact that this is somehow a technical decision leads |
| 67 |
me to suspect that more of Portage is also horribly broken. |
| 68 |
</rant> |
| 69 |
|
| 70 |
-- |
| 71 |
Batou: Hey, Major... You ever hear of "human rights"? |
| 72 |
Kusanagi: I understand the concept, but I've never seen it in action. |
| 73 |
--Ghost in the Shell |
Archives