| 1 |
On Tue, 14 June 2011 Brian Harring <ferringb@×××××.com> wrote: |
| 2 |
> On Tue, Jun 14, 2011 at 10:08:54AM -0400, Rich Freeman wrote: |
| 3 |
> > On Tue, Jun 14, 2011 at 8:54 AM, Brian Harring <ferringb@×××××.com> wrote: |
| 4 |
> > > The implicit system set dependency thing really, really needs to die; |
| 5 |
> > > at the time of the rule, portage couldn't handle resolving graphs of |
| 6 |
> > > that sort. ?PM resolvers for gentoo are generally a fair bit saner |
| 7 |
> > > now thus doing what you're suggesting isn't really beneficial (frankly |
| 8 |
> > > it causes some issues for stages, as zac noted). |
| 9 |
> > |
| 10 |
> > ++ |
| 11 |
> > |
| 12 |
> > It seems to me that the best policy would be for every package to just |
| 13 |
> > list all its dependencies, and then users are free to run the default |
| 14 |
> > experience that includes everything in @system, or a more trimmed-down |
| 15 |
> > experience. |
| 16 |
> |
| 17 |
> An annoying, but valid complaint agains this is that the deps start |
| 18 |
> getting heavy to maintain for developers, and aren't always viable to |
| 19 |
> represent. Unpackers for example, are a pain in the ass for current |
| 20 |
> EAPIs- that could be reduced in pain via addition of basic implicit |
| 21 |
> deps to EAPI5 (if a src_uri ends in .bz2, then dep on virtual/bzip2). |
| 22 |
> |
| 23 |
> Or devs could just be nudged into adding the appropriate DEPEND. |
| 24 |
> repoman checking for it either way wouldn't be hard. |
| 25 |
|
| 26 |
IMHO a big distinction between DEPEND and RDEPEND should be done. |
| 27 |
|
| 28 |
For RDEPEND all dependencies should be listed (including those packages |
| 29 |
provided by @system) |
| 30 |
This would allow easy installing into chroots with package manager's |
| 31 |
help, especially in combination with binary packages. |
| 32 |
|
| 33 |
For DEPEND it could be sufficient to assume @system is present or at |
| 34 |
least limit to those dependencies needed by the package/ebuild itself, |
| 35 |
but not those coming implicitly with features of package manager used |
| 36 |
(e.g. default unpacking, emake, einstall, do*) |
| 37 |
Eclasses "extending" package manager features should include their extra |
| 38 |
DEPEND needs. |
| 39 |
|
| 40 |
|
| 41 |
On the other hand, it would be nice if package manager could auto-detect |
| 42 |
at least part of the runtime dependencies (library linking should be easy |
| 43 |
as package manager already looks for them -- what's completely missing |
| 44 |
is shebang/interpreter dependencies). |
| 45 |
This way only version constraints would need to get added to RDEPEND |
| 46 |
inside ebuilds as needed (and the few cases where dlopen makes it |
| 47 |
impossible for package manager to see the linking). |
| 48 |
|
| 49 |
A nice benefit of this would be that it can adapt to changes caused by |
| 50 |
INSTALL_MASK, e.g. reduces dependencies that are not needed anymore |
| 51 |
because some files were not installed. |
| 52 |
|
| 53 |
Bruno |
Archives