public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev]  Re: splitting build deps out from depends
Date: Fri, 01 Jul 2005 20:48:15 -0700	[thread overview]
Message-ID: <pan.2005.07.02.03.48.14.687374@cox.net> (raw)
In-Reply-To: 20050701183536.GR19598@kfk4ever.com

Maurice van der Pot posted <20050701183536.GR19598@kfk4ever.com>,
excerpted below,  on Fri, 01 Jul 2005 20:35:36 +0200:

> If the point is to make dependencies complete, isn't there a way to
> build in some support for detecting it into some tool or other?
> 
> If we have a program that can create an environment and detect which
> programs are run within the environment (maybe sandbox can do this,
> maybe something with LD_PRELOAD, I'm sure we can think of something),
> then we can build a list of programs that are run during the build. 
> If we have such a list, we can find out which packages are required 
> to provide the tools in the list. 
> 
> Such a tool could be used to generate the correct build dependencies
> automatically or verify the existing bdeps.

If the other subthread touched on this, I missed it.  Just because an
executable may be used if there, doesn't necessarily make it a depend. 
Such a tool will document the path to configuration and compilation used
in the particular case of the system at the time it was run, but many of
those "dependencies" are one of several options (could be handled by
virtuals, tho such would have to be hashed out and added to a list that
said tool uses over time, and then we have the issue of making the tool
smart enough to know when the virtual is required, vs. when a specific
instance of that virtual is required) or are only used if present, with
another path entirely taken if not.

It might be possible to create a tool that could help automate /some/ of
this, but getting it all right even a simple majority of the time would be
very challenging and complex.  Basically, to get it right, you'll have to
have a human skilled in that sort of thing parse the output and match it
against the actual package behavior, anyway.  Thus, in ordered to have any
sort of consistency, the requirement would be an entire team of devs doing
little else but verifying this information, since many ebuild maintainers
would be as out of their depth as someone who's only worked on x86
scripting all their life would be with ppc64 bitness AND endianness
issues. That's a LOT of developer infrastructure we are talking about
creating and supporting, and a LOT of developer resources that therefore
won't be available for other things, when developer resource shortages
/already/ exist.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list



      parent reply	other threads:[~2005-07-02  3:51 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
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   ` Duncan [this message]

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=pan.2005.07.02.03.48.14.687374@cox.net \
    --to=1i5t5.duncan@cox.net \
    --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