| 1 |
Aron Griffis wrote: |
| 2 |
> George Shapovalov wrote:[Mon May 26 2003, 02:49:36PM EDT] |
| 3 |
> |
| 4 |
>> As such it makes sense to put some absolutely something basic in |
| 5 |
>> DEPEND for the package which does not have any apparent (as |
| 6 |
>> non-trivial, not bad-researched) dependencies. In that respect |
| 7 |
>> virtual/glibc perfectly fits the bill... |
| 8 |
> |
| 9 |
> |
| 10 |
> DEPEND="" works just as well. Since glibc is in the default profile, |
| 11 |
> there's no reason to list it as a dependency, just like we can |
| 12 |
> assume some basic shell utilities are present when the ebuild is |
| 13 |
> processed. |
| 14 |
> |
| 15 |
|
| 16 |
Depending on the degree you are talking here, I tend to disagree with |
| 17 |
the notion of not including some so call "basic" dependencies, because |
| 18 |
profiles can have variations that may include stripping out some core |
| 19 |
components. As we move into the embedded realm, the definition of our |
| 20 |
"core profile" will need to be reduced, so adding full dependency |
| 21 |
information now is not necessarily a bad thing. |
| 22 |
|
| 23 |
Instead, we need to clarify a truly minimal system set of packages (such |
| 24 |
as libc) for which their dependency information need not be included. |
| 25 |
This will probably be taken up as part of the embedded project's efforts |
| 26 |
to scale the system down, so there is not pressure to do this now. |
| 27 |
|
| 28 |
The tools already exists to build a dependecy list by tracking what the |
| 29 |
actual build process uses during execution, and I have seen a couple of |
| 30 |
ebuilds in the tree that seem to have used them. This may not be a bad |
| 31 |
standard practice to follow if those few core packages can be put on a |
| 32 |
'whitelist' for exclusion by those tools. At some distant point, |
| 33 |
automating this process with a tool would not be a bad thing: |
| 34 |
|
| 35 |
emerge --makedeps package-1.0.ebuild |
| 36 |
|
| 37 |
This would build the package, tracking the deps, and modifying the |
| 38 |
ebuild to update the build dependencies. The recent thread that talked |
| 39 |
about collecting branch prediction information by automatically running |
| 40 |
the program a few times suggests to me that a similar process could be |
| 41 |
applied to also detect RDEPENDS. The above flag should also imply the |
| 42 |
use of --digest run as a finalization step. |
| 43 |
|
| 44 |
Cheers, |
| 45 |
|
| 46 |
Zach Welch |
| 47 |
Gentoo Embedded Lead |
| 48 |
Superlucidity Services |
| 49 |
|
| 50 |
|
| 51 |
|
| 52 |
-- |
| 53 |
gentoo-dev@g.o mailing list |
Archives