Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: Gentoo Developers <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Stage1 and dependencies
Date: Sat, 26 Jun 2004 10:17:02
Message-Id: 20040626095231.GB7174@curie-int.orbis-terrarum.net
In Reply to: Re: [gentoo-dev] Stage1 and dependencies by Jason Stubbs
1 On Sat, Jun 26, 2004 at 06:27:30PM +0900, Jason Stubbs wrote:
2 > -----BEGIN PGP SIGNED MESSAGE-----
3 > Hash: SHA1
4 >
5 > On Saturday 26 June 2004 17:06, Robin H. Johnson wrote:
6 > > On Sat, Jun 26, 2004 at 03:06:52PM +0900, Jason Stubbs wrote:
7 > > > Issue #1: Ignoring dependencies
8 > > > The "cleaning" of the vardb to trick portage is IMO a bad thing. There is
9 > > > obviously enough in a stage 1 to be able to build up all of system, but
10 > > > according to the data portage it is impossible. This then requires a hack
11 > > > as indicated above to attempt the merge anyway. However, this hack
12 > > > affects users of installed systems as well as portage will go ahead and
13 > > > attempt a compilation that is guaranteed to fail.
14 > > What's your solution for this?
15 > Well, I don't actually understand why the var db needs to be cleaned. I can't
16 > see why a combination of --nodeps and --onlydeps on package x and y can't
17 > solve whatever the problem is, though...
18 Try it and see :-), if you don't see why it shouldn't work, it should
19 probably work... if not fix it ;-).
20
21 > > I've got no objections to putting the correct information into the tree,
22 > > but portage needs to be able to handle circular dependancies much better
23 > > first. One other glaring problem in your listing is sys-devel/make. One
24 > > other thing that will bite at some points is the things that some
25 > > upstream developers put into their configure scripts, that are decidedly
26 > > not always present on a system (perl and rpm to name the worst offenders
27 > > I've seen). If you can tell me I won't run into any problems by adding
28 > > in the deps for virtual/libc virtual/cc sys-devel/make etc into my
29 > > packages, I'll go around and correct them now.
30 > I don't think that the change would bring about any more bad dependency
31 > ordering than already exists, but I can't be sure. Perhaps, the solution is
32 > to fix the dependency resolver then fix the packages and then enable parallel
33 > emerges. That sound acceptable?
34 Yup, that should be fine. Before .51 comes out, could you maybe add a
35 bit of code in repoman to detect circular dependancies (and give a
36 non-fatal warning at the moment), so we can work on them from an early
37 stage?
38
39 I see two cases of circular dependancies that need to be worried about:
40 - Directly:
41 pkgA DEPEND on pkgB, and pkgB DEPEND on pkgA - The only solution here
42 is to code something to work around the circular dependancy, via
43 bootstrapping one of the packages (similar to getting gcc onto a
44 machine without a compiler). I know at least one case of this existing
45 in the tree at a point, but I think it's been fixed at the moment.
46
47 - Conditionally directly:
48 openldap:DEPEND="sasl? ( cyrus-sasl )"
49 cyrus-sasl:DEPEND="ldap? ( openldap )"
50 This one is much simpler, just build one of the two without the USE
51 flag that causes the circular trap. Then build the other package, and
52 rebuild the first. Hard part would be choosing which one to build
53 without the USE flag. A few bugs like this exact one exist, see bug
54 #33440 to track them.
55
56 > > virtual/cc is something I think should exist, as some people want to use
57 > > dev-lang/icc or dev-lang/ccc instead of sys-devel/gcc.
58 > >
59 > > Also, where does the adding of dependancies stop? Eg I have something
60 > > that uses kernel-headers and glibc, so do I just specify glibc and
61 > > ignore kernel-headers as that's needed by glibc?
62 > That's a design question that's open to debate. Portage can do it either way,
63 > but I would suggest that the package depend on both kernel-headers and glibc
64 > for robustness in the tree. Unlikely in this case, but it ensures that a
65 > change to glibc's dependencies don't break the packages that depend on it.
66 Ok, so listing as many dependancies as required (within reason) is
67 suitable. One other question comes up in your mention of eclasses to
68 make it easier, namely what's the speed hit going to be with so many
69 eclasses being added to packages? Won't it be better to change ebuilds
70 directly?
71
72 --
73 Robin Hugh Johnson
74 E-Mail : robbat2@××××××××××××××.net
75 Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
76 ICQ# : 30269588 or 41961639
77 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

Replies

Subject Author
Re: [gentoo-dev] Stage1 and dependencies Jason Stubbs <jstubbs@g.o>