Quoting Nelson Marques <nmo.marques@gmail.com>:
Hi all, Furthermore... the typelib package naming policy. In the case of muffin/cinnamon, the typelib is internal and not public, which eventually falls out of the current typelib policies (since we are only considering public typelibs in the policy). Could this be allowed also:
- typelib(Meta) = 3.0
This ain't a valid package name, and the provides is automatically added by gobject-introspection magic... BUT: there is the problem: introducing a 2nd package in Factory will create a 'have choice for typelib(Meta)' issues... same will be for zypper: it won't be able to decide which one is used/needed/required. This should get high prio fixing upstream imho.
Can we have the package named as typelib-3_0-libmuffin-0_0 ? And I would maybe suggest that internal typelib's could be packaged that way, so we have a distinction just by looking at the package name we know that:
I'm not sure if the 'parts' of the original naming convention are clear, but this violates pretty much all of them: correctly named packages are: typelib-1_0-Meta-3_0 (for a file installed as %{_libdir}/girepository-1.0/Meta-3.0.typelib) 1) typelib: this is a typelib gi binding. (literal) 2) 1_0: The typelib namespace version. (There are plans to bump to 1.2 or (maybe later 3.0?). Those must not conflict 3) Meta: The name of the typelib, unversioned. 4) 3_0: The version of the typelib. For internal typelibs it would be acceptable to package it in the package directly and not split it out (likely can't be in the slpp package though, as you're likely to face extensive explicit dependencies on a library package). Packaging this specific file in 'Muffin' directyly sounds reasonable (the .typelib file creates a dependency on the libmuffin.so.0 symbol)
* libmuffin has a internal typelib (we don't know if it's Meta or anything else, but we can easilly find out with "rpm -qp --provides package").
I'm not sure if the lib is using the typelib (unlikely) or something else.. so the statement is likely wrong (but that's implementation specifics) Best regards, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org