On Mon, Mar 15, 2010 at 03:49:16PM +0100, Max Horn wrote: > 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...
Lots of weird dependency problems (usually upgrade deadlocks) have happened when I tried that in some places. One common case is an existing foo:depends:foo-split(=%v-%r) when foo-split becomes obsolete and moves from foo.info to foo-split.info. Fink seems smart enough to do atomic update of multiple packages in a single .info. But in separate .info, if foo-split is in the upgrade pile first it will fail because upgrading it would break the existing dep of foo on it. dan > 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). I still love this feature idea--always seemed like a very rare need to have it though (this is one of the few I can think of where we have a runtime requirement that isn't also a buildtime one). There are some hooks in the engine already for it (related feature: actual Shlibs dependency support), but I assume that because it hasn't been used other things have been changed and may need hacking to respect it. Conflicts actually is not parallel to the Depends behavior: Conflicts is only a runtime thing, not implicitly also included in BuildConflicts. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ 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 Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
