OK, I just checked in yet another attempt to fix this darn issue. I hope that it is correct this time. I actually used pen & paper and played through various scenarios to try to fully grok this.
One issue is back that had been fixed with the previous checkin: if you have a package foo with a splitoff "foo-shlibs", and the parent "foo" depends on "foo-shlibs", then "fink build foo" will force you to install foo-shlibs, even though this is not strictly necessary. While this might be annoying, it's quite harmless, and not strictly spoken incorrect, just not necessary either. Working on this issues, I realized two things: 1) Fink assumes that the build deps are a true superset of the regular dep list. This makes some sense, since it simplifies the install code logic, but takes a bit away from the flexibility of that code. I think I know a way to improve the situation (fixing the problem mentioned above): instead of just distinguishing between "install" deps and build deps, we could distinguish between three kinds: install deps, build deps and build&install deps (the last one would simply be the union of the previous two). But I don't want to mess with that code right now, not when it's so late that I can barely keep my eyes open 8-) 2) Fixing this is so hard partly because of our (IMHO still valid) decision to go with "foo" & "foo-shlibs", as opposed to debians "foo-dev" & "foo". You see, when you have a package with splitoffs, there always has to be (and always will be) at least one package among the splitoffs and the master which does *not* depend on any of the other splitoffs or the master. I call such a package "central". For example, this is always true for -shlibs splitoffs. If we had gone with Debian's approach, then what we now call foo-shlibs would be the parent package, and thus parent package would be central. In fact, we then could arrange it so that the parent is always central. Right now this is impossible. Why is this so important? Well, when want to build & install multiple of the splitoffs/parent of a single package, then we have to install them in a certain order, and one has to come first. And that one has to be a central package, otherwise dpkg complains about dependencies not met and bails out. So, we have to find a central package amongst these. If we knew the parent was always central, we could just use it, and resolve_depends could become cleaner. But sadly it's not so easy, and we have to spend some effort to find a suitable package among the splitoffs and the parent. Personally, I am not very happy with the current code in resolve_depends. It's IMHO quite hard to understand (please look at it and judge for yourself). Code which is hard to understand leads to bugs and misunderstandings, and needs comments, of which I added a few. But I am not sure if it's possible to understand the reasons for some of the things I did there, even with the comments and my above explanation for some of the motives. Maybe I can try to rewrite this code in a clean fashion from scratch eventually, but for now, I better head off to bed :-) Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
