public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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 --]

  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