On May 6, 2008, at 10:33 PM, Daniel Macks wrote: > On Tue, May 06, 2008 at 10:17:32PM -0700, David R. Morrison wrote: >> I've tried to write an expanded error message for the situation where >> the validator encounters a shared library in a .deb which is not >> listed in the Shlibs field. (The code is in HEAD, but not yet >> released.) Here's a sample error message: > > Yeah, we need to make people understand it. OTOH, the more detailed we > make this message, the more special-cases slip through... > >> Validating .deb file fontforge_20080330-1_darwin-powerpc.deb... >> Error: package contains a shared library >> /sw/lib/fontforge/libfontforge.1.0.0.dylib >> but the install_name and compatibility_version >> (%p/lib/fontforge/libfontforge.1.dylib 2.0.0) >> are not listed in the Shlibs field. If this library is >> public, in the >> sense that it may be linked to by other packages, then these >> must be >> listed in the Shlibs field, along with versioning information >> about the >> package providing the library. However, if this is a private >> library >> which will be used only by this package, add >> '!%p/lib/fontforge/libfontforge.1.dylib' >> to the Shlibs field. > > "the install_name and compatibility_version [...] are not listed in > the Shlibs field." But then later is an instruction to list *only* the > install_name (not c_v).
Well, the word "these" was supposed to indicate both i_n and c_v. The idea, as I understand it, is that public libs should have i_n c_v %n <some version stuff> with i_n in the "%p" form, whereas private libs only need !i_n. But the antecedent to "these" is not so clear, I now recognize, so this should be reworded. > Also, don't want to parenthesize the i_n and > c_v, since it suggests that that's the Shlibs: syntax (likewise, no > single-quotes on the private-shlibs syntax). Agreed. > The code in HEAD does a regex match for %p (which is good--better to > use that literal in the Shlibs info instead of hardcoding /sw or > whatever in the error msgs) but there are legit packages that install > outside of %p and still need standard Shlibs handling. Really? What packages install outside of %p, other than legacy X11 packages in 10.4? (I guess those should be handled.) > Not quite sure > what the else{} block is supposed to catch. I *think* it traps > install_name that isn't an absolute path? Need to anchor the regex > pattern to the beginning of the string, and it's still leaky > (especially for a libtool or hand-coded-alternative screwup) if it > points to the build dir (since that's a subdir of %p). Would it be > better to do the main message if it's *any* absolute path (i.e., not > just in $basepath) but still s/^basepath/%p/ for the displayed > message and the else{} if a non-absolute one? Probably the best would be to do a syntax check on install_name *before* this test, and then fall through to this test where s/^ $basepath/%p/ will definitely be true. -- Dave ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel