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
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
