Hi, Le vendredi 10 février 2012, à 10:55 +0000, Nelson Marques a écrit :

Hi all,

There's currently a tiny issue regarding the submission of Cinnamon identified by Coolo and Vincent (assuming). The Muffin package (a fork of mutter) typelib has the same name that mutter's. Currently everything seems to work, and though this library is internal to mutter/muffin it might bring issues in the future.

This was taken upstream which will fix it, but not yet for the next release (due to the large number of changes required). My question is, since currently (maybe out of pure luck) we haven't any report of real issues, could we allow this in Factory until it gets fixed (most likely before the release 12.2) ?

I don't think it's a big issue to release with this at the moment.

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

Not sure what the question here is :-)

Can we have the package named as typelib-3_0-libmuffin-0_0 ? And I

Let's see what Dominique thinks, but to me, that sounds really wrong since the name doesn't really match anything existing.

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:

* 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").

For reference, what we're doing in other packages with a private typelib is that we're simply not putting them in a subpackage. And I think that's probably the best solution; it might create a few issues with the generator of automatic dependencies, but I'd say it could be disabled in this case. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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