| 1 |
On Thu, 25 Oct 2007 22:14:40 -0700 |
| 2 |
"Alec Warner" <antarus@g.o> wrote: |
| 3 |
|
| 4 |
> > Another issue that isn't directly related, but covered by the |
| 5 |
> > proposed solution below, is the so called "implicit system |
| 6 |
> > dependency" in ebuilds, which doesn't really exist. It only an |
| 7 |
> > assumption by people that the "system" set is satisfied before an |
| 8 |
> > ebuild is processed, so its contents don't have to be listed in |
| 9 |
> > *DEPEND. If a user breaks that assumption by not regulary ensuring |
| 10 |
> > that "system" is satisfied bugs can occur. Another issue is the |
| 11 |
> > informal exception when system items are allowed to/must be listed |
| 12 |
> > in *DEPEND, IMO that should be formalized. |
| 13 |
> |
| 14 |
> I'm going to discuss a bit your implementation below, since you |
| 15 |
> address what you are trying to solve here. My main problem is that |
| 16 |
> given a tree (such as gentoo-x86) it may have one or more profiles |
| 17 |
> with one or more sub-profiles (children). These profiles may contain |
| 18 |
> a set of packages that make up 'system'. The ebuilds DEPEND (or |
| 19 |
> RDEPEND or whatever) on this set of packages existing. The problem I |
| 20 |
> see with your solution is that it doesn't address different system |
| 21 |
> sets in different profiles. Now in practice this isn't much of a |
| 22 |
> problem within gentoo-x86 (most profiles have similar system sets). |
| 23 |
> However it places a certain onus on any profile in a given tree, it |
| 24 |
> must have a system package 'similar' enough to other sets in |
| 25 |
> functioning profiles; otherwise breakage is likely to occur. How |
| 26 |
> would you address this in your system? |
| 27 |
|
| 28 |
How is the problem solved now? Remember that I'm just proposing to |
| 29 |
formalize existing assumptions (packages in "system" should state all |
| 30 |
their dependencies explicitly). The answer is that there is no real |
| 31 |
solution to that "problem", at least not without creating a huge mess by |
| 32 |
enumerating all available profiles. |
| 33 |
The real question is what "system" is supposed to be. Is it just a more |
| 34 |
or less arbitrary list of packages chosen by the profile maintainer, or |
| 35 |
does it have a global, predefined purpose, like defining the minimum |
| 36 |
requirements for packages in the associated tree? In the first case the |
| 37 |
second part of my proposal obviously doesn't work, as you can't make |
| 38 |
any valid assumptions about "system". In the second case however the |
| 39 |
purpose already mandates that the content of "system" is effectively |
| 40 |
identical across different profiles. |
| 41 |
|
| 42 |
Marius |
| 43 |
-- |
| 44 |
gentoo-portage-dev@g.o mailing list |
Archives