On Wed, Apr 28, 2010 at 09:44:02AM -0400, Alexander Hansen wrote: > On 4/28/10 9:22 AM, Jack Howarth wrote: > > One piece of legacy coding left in the gcc4x packages > > which perplexes me is the use of... > > > > %N-shlibs (>= %v-%r) > > > > instead of... > > > > %N-shlibs (= %v-%r) > > > > for the Depends field of the main gcc4x package. Was there > > a bug in fink at some point that required the use of >= > > rather than =? I was going to change that as well but > > wanted to make certain there wasn't some obscure reason > > for that particular conditional. > > Jack > > > Convenience, possibly. The bug hasn't gone away. > > If the main package has Depends: %N-shlibs (= %v-%r), if a user has the > main and -shlibs installed they can't update to a new version-revision > in one step. The build will be performed, but fink won't install the > update: the new -shlibs has to go in first, and the old main package > will complain because of the %v-%r mismatch. But afterwards apt-get is > perfectly happy to figure out how to do the upgrade. > > I'd argue that (= %v-%r) is a safer option.
I think fink's SysState fixed that bug. If you have installed the pair with %N:Depends:%N-shlibs(=%v-%r) and you "fink update %N-shlibs" to a newer version or revision, fink should recognize that 1) this will break the dependency of the installed %N, and 2) that simultaneously updating %N will solve he problem, and so do it that way. It may not be able to handle looking more deeply into the dep tree and it might not work if %N and %N-shlibs are not in the same .info file (two splitoffs, or one splitoff of another)...can't remember how robust the thing is. For libraries, the = actually prevents breakage of symlinks. For example, foo1-dev has libfoo.dylib->libfoo.1.0.1.dylib, with libfoo.1.dylib (the install_name) and libfoo.1.0.1.dylib in foo1-shlibs. Now comes a new package version (same install_name) that has libfoo.1.0.2.dylib istead of libfoo.1.0.1.dylib. "Just" updating the -shlibs package (allowed by a >= dependency) breaks the libfoo.dylib symlink, which also breaks building of any package that "BuildDepends:foo1". Using = means they stay in sync. Using = also means the .h and other compile-time files and tools are perfectly (self-consistent set) matched to the .dylib. I don't know what happens if gcc (the front-end programs) from one %v of a gcc suite are used with the libraries (-shlibs package) from a different one. No idea if there are symlinks and other pointers that break (recent libtool2 uses libfoo.dylib->libfoo.1.dylib not ->.1.0.whatever). dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ _______________________________________________ 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
