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 |