On 8/31/05, Steven Stromer <[EMAIL PROTECTED]> wrote: <snip> > > > Martin, > > Thank you for your informative responses. I am concerned that libofx may > be prematurely removed. If you've got a second, please look for the > thread titled 'libofx package in the Bermuda triangle?' in the > gmane.os.apple.fink.general list.
Martin posted in that thread so he's aware of it. ;-) I found, a week before this last > update that gnucash and gnucash-docs would not function without libofx, > and that libofx-shlibs and libofx1 would not fix the problem. The > package maintainer reposted libofx to get things to work, and > acknowledged that the dependency had been accidentally broken by the > removal of libofx. Should I be assuming that gnucash and gnucash-docs > were somehow updated this past week to no longer need the original > libofx, and that this is why libofx has been removed? Nope--no updates in that interval. Backing up this > assumption is the fact that gnucash and gnucash-docs are still working > now, even though libofx has been removed. > The reason you _can_ remove libofx is because it's a build-time rather than a runtime dependency. . > Thus, my original question regarding the phasing out of a package > remains partly answered. Where can I learn more about what happens to a > package when it is no longer part of the distro? Again, using the > example of libofx, what, for instance, makes package management software > so confident that I don't need this package for my own purposes that it > assumes the validitiy of its decision to remove the package from my > configuration? A pointer to where I can read more would be great. > Check out http://fink.sourceforge.net/doc/packaging/index.php In the case of libofx / libofx1 the packages are specifically tagged as BuildDependsOnly, meaning that they aren't required at runtime, and nothing should declare a runtime dependency on them. The package management software is "confident" that libofx can be removed because the the human package maintainer is confident that it can be removed and has set things up accordingly. This process is of course not infallible as you have already found out. > Thanks again for your generous assistance, > > Steven > > > > -- Alexander K. Hansen Fink Documenter [Day Job] Levitated Dipole Experiment http://psfcwww2.psfc.mit.edu/ldx/ ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Fink-beginners mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-beginners
