fink-obsolete-packages annoyance
Max Horn <max <at> quendi.de>
2010-03-15 14:49:16 GMT
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
Fink-devel <at> lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
RSS Feed