[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 #6 from Andoni Morales <ylatuya at gmail.com> 2014-04-05 11:46:27 UTC ---
(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.

> The patch does exactly the same for .dylibs as is already implemented for
> Windows DLLs.

It does not do the same thing as in Windows, because in Windows both
bin/libfoo.dll and bin/libfoo-1.dll are runtime libraries and the link
libraries are in lib/libfoo.dll.a and lib/libfoo.lib.

> 
> > 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']}

-- 
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.