Hi there, so last night I finally made the move from OS X 10.5 to 10.6. As part of that, I reinstalled Fink from scratch. This went mostly fine, but there were a couple of annoyances, one of which I want to describe here:
Several packages, among them libcurl4 and coreutils (maintainers CCed), forced me to install the fink-obsolete-packages package -- even though I installed nothing that was obsolete. The reason for this is of course that these packages have obsolete splitoffs, which depend on fink-obsolete-packages and hence pull in fink-obsolete-packages. This is not very nice, IMO. For me personally it's easy to determine that the dependency on fink-obsolete-packages is only an unwanted side effect and I just removed it after those packages installed. But for users in general, this seems like a negative experience... they install a brand new package and suddenly see something about obsolete stuff being installed. Not nice :/. I am not sure what the best way is to resolve this, but I hope that it can be resolved ... one idea that comes to mind is forbidding splitoffs to depend on fink-obsolete-packages, i.e. enforcing a policy where either all splitoffs (including the master splitoff) in an .info file depend on fink-obsolete-packages, or none. In this particular case that would mean that the obsolete splitoffs needs to go to separate .info files. That seems easy enough to do, however, I am not sure whether this couldn't cause some other weird dependency side effects, when upgrading from old package versions... The other alternative would be to implement the ancient idea of an "RuntimeDepends" (or "InstallDepends", or whatever) field. I.e. a field which is kind of the complement of BuildDepends: Any dependencies declared in it only count when installing the package, but do *not* count towards build dependencies. Then, fink-obsolete-packages could be a RuntimeDepends. I vaguely recall that in the past, we had other cases which might benefit from such a field (and the analogous RuntimeConflicts / InstallConflicts field), although the details elude me right now. It would be quite easy to add this field, but the fact that it doesn't yet exists might indicate that it's a bad idea for some reason I am not seeing right now, or that it's simply not useful enough to warrant adding it (and thus bloating the .info syntax further). Thoughts, suggestions? Cheers, Max ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
