On Sun, Dec 06, 2009 at 10:41:15AM -0500, Koen van der Drift wrote:
> Moving this to fink-devel.
>
> I saw that Dan fixed this issue in cvs - thanks!
>
> So if I understand correctly, the problem was that I used %N-plplot6-
> shlibs instead of %N-plplot3-shlibs, is that correct?
Right. The essence of the policy is that there must be a 1:1 mapping
of Shlibs filename entries and the Package name that contains them. If
that filename changes (for example, nucleus.5.dylib ->
nucleus.6.dylib) then the packagename must change
(emboss-nucleus5-shlibs -> emboss-nucleus6-shlibs). During the emboss
upgrade from version 5.x to 6.x, libeplplot.3.dylib kept its same
filename, but the packagename was changed emboss-plplot5-shlibs ->
emboss-plplot6-shlibs, which means those packages fight over who
supplies the file and other packages cannot specify a reliable Depends
entry if they need that file. Collision of runtime files among
multiple packages is bad.
So the package-names of a shared library really have nothing to do
with the upstream source version, but only to do with the specific
library *file* they contain. For convenience, it's become a
best-practice to name the -shlibs package (and its matching -dev) to
contain the same versioning as the that library file. So (once I was
in "make it clean mode, given we already have some breakage" mode) I
used emboss-plplot3-shlibs as the one new consistent place for
libplplot.3.dylib, just like the libnucleus filename number matches
for *its* package, etc.
This is the change we had discussed and I finally did in the early
days of emboss, leading to the DescPort note:
dmacks overhauled splitoff layout so that lib versions can float
against each other
> But I am a bit unsure about the changes that were made in the patch
> file, what are those for?
The .patch change is the other DescPort note, a change that got lost
in some release since I had implemented it:
dmacks added explicit linking to libs that supply symbols used by
the shared libraries here. This prevents things that link against
the shared libraries from having to know to pass additional flags
when the linker requires all symbols be defined.
It's an upstream bug that "probably" has no user-visible effect. But
if it does, the whole fink support team will spend days trying to sort
it out and passing the blame all around. In essence, libeplplot uses
libgd but does not use -lgd when being compiled and does not publish
this information ("need to use libgd when you use libeplplot") in a
useable way. That means any other package that ever wants to use
libeplplot must somehow magically know to load libgd first, or else
suffer a compile-time or run-time error. So I added -lgd. Same for a
few other of these "missing links".
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
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
