From: Drake Wyrm <wyrm@haell.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] splitting build deps out from depends
Date: Fri, 1 Jul 2005 15:59:00 -0700 [thread overview]
Message-ID: <20050701225900.GA8904@phaenix.haell.com> (raw)
In-Reply-To: <200507011349.19312.vapier@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]
Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote:
> > Currently, we pretty much leave out the big dogs of build depends from
> > ebuilds- basically we rely on the profile to require a suitable
> > toolchain. Couple of issues with this though-
>
> so what you're proposing is that we add binutils/gcc/glibc to every package
> that compiles something
Can you compile without binutils/gcc/glibc? No? Then you need it.
> make to every package that uses make,
Again, if you depend on make, then DEPEND on make.
> sed/grep/bash/coreutils to every package which runs configure
That's quite an interesting case. Yes, those should be in DEPEND, but it
might be prudent to create an appropriate shortcut instead of explicitly
adding each of those.
Three possibilities come to mind.
0) For ebuilds which use the standard GNU autoconf-generated configure
script, a standard set of tools could be added to DEPEND from a
standard variable.
DEPEND="${ac-configure} dev-libs/libwombat app-misc/imanotherdep"
where ${ac-configure} expands to everything that runs in yer typical
configure script.
1) Use the eclasses. Right before inheriting eutils, provide a token to
tell eutils to add some appropriate DEPEND tokens.
ac-configure=yup
inherit eutils
Many of the eclasses add a few DEPEND tokens. Use the standard
eclass(es) to add the standard DEPENDs.
2) Well, maybe cramming this into eutils isn't such a hot idea, but
creating an eclass for the purpose of adding the generic dependencies
would work better.
edeps="configure make c-tools"
inherit edeps
> tar/gzip/bzip2 to every package which has a gzipped/bzipped tarball in
> SRC_URI ?
Now this could _definitely_ play into suggestion (2) above. Have the
edeps eclass check the SRC_URI and add the appropriate unpacking
packages.
edeps="make"
SRC_URI="http://www.wombats.com/i_need_tar_and_bzip2.tar.bz2"
inherit edeps
Whee.
<rant class="flame">
I know this will be shot down, as it has been shot down each time in the
past that somebody has suggested it. I wish it were not the case. Almost
every ebuild in the tree fails to completely and accurately reflect its
dependencies. The fact that this is somehow a technical decision leads
me to suspect that more of Portage is also horribly broken.
</rant>
--
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
--Ghost in the Shell
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2005-07-01 23:01 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-01 16:25 [gentoo-dev] splitting build deps out from depends Brian D. Harring
2005-07-01 17:49 ` Mike Frysinger
2005-07-01 18:03 ` Diego 'Flameeyes' Pettenò
2005-07-01 18:11 ` Brian D. Harring
2005-07-01 18:30 ` Mike Frysinger
2005-07-01 18:42 ` Brian D. Harring
2005-07-01 18:46 ` Brian D. Harring
2005-07-01 18:53 ` Diego 'Flameeyes' Pettenò
2005-07-01 19:10 ` Brian D. Harring
2005-07-01 20:25 ` Paul de Vrieze
2005-07-05 9:39 ` Martin Schlemmer
2005-07-07 11:56 ` John Myers
2005-07-07 19:44 ` Kito
2005-07-07 20:45 ` Diego 'Flameeyes' Pettenò
2005-07-09 9:28 ` Jason Stubbs
2005-07-01 18:37 ` Diego 'Flameeyes' Pettenò
2005-07-01 22:59 ` Drake Wyrm [this message]
2005-07-02 1:16 ` Kito
2005-07-04 0:18 ` Brian D. Harring
2005-07-09 9:28 ` Jason Stubbs
2005-07-05 10:48 ` Martin Schlemmer
2005-07-05 23:17 ` Brian Jackson
2005-07-06 1:46 ` Martin Schlemmer
2005-07-06 1:59 ` Brian Jackson
2005-07-06 2:39 ` Martin Schlemmer
2005-07-06 17:08 ` Brian D. Harring
2005-07-07 13:29 ` Martin Schlemmer
2005-07-09 9:28 ` Jason Stubbs
2005-07-09 9:45 ` Diego 'Flameeyes' Pettenò
2005-07-09 9:28 ` Jason Stubbs
2005-07-09 10:17 ` Martin Schlemmer
2005-07-09 9:28 ` Jason Stubbs
2005-07-09 9:47 ` Diego 'Flameeyes' Pettenò
2005-07-09 10:20 ` Martin Schlemmer
2005-07-09 11:45 ` Diego 'Flameeyes' Pettenò
2005-07-09 12:01 ` Martin Schlemmer
2005-07-09 12:08 ` Diego 'Flameeyes' Pettenò
2005-07-09 12:37 ` Stephen Bennett
2005-07-09 12:41 ` Martin Schlemmer
2005-07-09 12:46 ` Diego 'Flameeyes' Pettenò
2005-07-09 13:05 ` Martin Schlemmer
2005-07-09 13:11 ` Diego 'Flameeyes' Pettenò
2005-07-09 14:10 ` Martin Schlemmer
2005-07-09 19:19 ` Kito
2005-07-01 17:58 ` Diego 'Flameeyes' Pettenò
2005-07-01 18:35 ` Maurice van der Pot
2005-07-01 18:45 ` Brian D. Harring
2005-07-01 18:56 ` Maurice van der Pot
2005-07-01 19:12 ` Brian D. Harring
2005-07-01 19:19 ` Maurice van der Pot
2005-07-02 3:48 ` [gentoo-dev] " Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050701225900.GA8904@phaenix.haell.com \
--to=wyrm@haell.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox