On Jul 1, 2005, at 5:59 PM, Drake Wyrm wrote:
Mike Frysinger <[EMAIL PROTECTED]> 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>
Well, {humans,monkeys,ebuild maintainers} can't be trusted to
accurately track a packages dependencies, be it build or runtime. The
way some other build systems deal with this is keeping a table
mapping files to packages, and simply monitoring every file touched
during compilation and runtime to generate deps.
Accurate deps should be a goal for the tree, a long term one
obviously...
Kito
--
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
--
gentoo-dev@gentoo.org mailing list
