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