[Bug 727534] cerbero: Add support for non-standard Darwin .dylib filenames

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=727534
  GStreamer | packages | unspecified

--- Comment #7 from Philip Withnall <bugzilla at tecnocode.co.uk> 2014-04-07 11:51:26 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > I am not sure this patch is completely correct as .dylib libraries are the
> > > libraries used at link time, similar to libfoo.so files in linux.
> > > The problem with this patch is that libfoo.dylib libraries that are now treated
> > > as link libraries and packaged in the development packages will be also
> > > packaged in the runtime package.
> > 
> > Looking at the output packages I have here, the dylib has been put in the
> > runtime package and not the development package. That makes sense to me. It’s
> > needed at runtime for dynamic loading, and also needed at development time —
> > but it seems to be entirely reasonable to require the developer to have both
> > the development and runtime packages available to compile against.
> > 
> 
> The problem is not with your particular library but with the rest of them that
> uses the regular naming scheme. At runtime libfoo.dylib is not needed since the
> runtime linker will use libfoo.x.y.z.dylib (check for instance the output of
> any library with otool -L), that's why we put them in the devel packages. With
> your patch libglib-2.0.dylib will be both in the development package and the
> runtime package which is wrong from a packaging point of view.

Ah, I didn’t clock that this would cause libfoo.dylib to end up in the runtime
package for normal projects.

> > > Can you please describe the project creating this kind of library?
> > > I think the correct fix is in the recipe's post-install step, moving
> > > libfoo.dylib to libfoo.0.dylib and link libfoo.dylib to libfoo.0.dylib.
> > 
> > The project doesn’t have an SO version (or its Darwin equivalent) set.
> > Unfortunately, that naming on the library is a requirement of the project, so
> > can’t be changed. Otherwise we would have done that already. :-(
> 
> Since yours is a special case, you can't modify the packaging rules for the
> rest of regular uses cases. If your library don't use the default naming scheme
> for libraries do not use the default libs category. You can use something like
> 
> platform_files_libraries = {Platform.DARWIN: ['lib/libfoo.dylib']}

I contend that this is a special case: it will happen for any library which
doesn’t specify a SO version. Still, if you feel that’s sufficiently special,
please revert my patch (I don’t have commit rights on the repository).

Thanks for the workaround. We’ll use that for now.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.