On Mon, Dec 10, 2018 at 1:22 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Mon, Dec 10, 2018 at 5:01 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>
> The libmodulemd library, used by the Module Build Service, libdnf,
> fedmod and other tools is going to be updated this week to version
> 2.0.0beta1. While this includes a soname bump, the Fedora packaging
> will include a compat-libmodulemd1 (and python3-compat-libmodulemd1)
> subpackage that is fully compatible with the 1.x API. I do not expect
> any problematic fallout from this upgrade and existing tools should
> continue to work fine until they can be ported to the newer API.
Hi,
Please don't use "compat-" package names, they are outdated.
The Packaging / Naming Guidelines have been amended some time ago, and
don't mention "compat-" anywhere anymore.
The relevant section for cases like this can be found here (Multiple
packages with the same base name):
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_multip...
So, according to these guidelines, the package names should instead be:
- libmodulemd (providing version 2.x)
- libmodulemd1 (providing version 1.x)
- python3-libmodulemd
- python3-libmodulemd1
OK, that's easy enough to do. I haven't done the builds yet.
> This will mean that anyone building against libmodulemd today
will
> need to change their spec files to indicate `BuildRequires:
> compat-libmodulemd1-devel` to continue using the 1.0 API.
It's unfortunate that the pkgconfig for modulemd isn't versioned.
Now both packages (libmodulemd-devel, and libmodulemd1-devel) will
provide 'pkgconfig(modulemd)',
It is versioned, actually. The 1.x API is `pkconfig(modulemd)` and 2.x
is `pkgconfig(modulemd-2.0)`. The source of the conflict between the
two -devel subpackages is that they both want to own
/usr/lib64/libmodulemd.so, symlinked to different objects.
but the newer version will always take precedence due to the higher
version.
Otherwise, packages could have explicitly requested the library with
the old API with BR'ing 'pkgconfig(modulemd-1)', and the new API with
BR'ing 'pkgconfig(modulemd-2)' (or something similar).
They can do this today, see above.
(BTW, do the old and new python packages' names contain the
version?
Otherwise they'll probably conflict.)
The python packages are actually just metapackages that `Requires:
python3-gobject-base`. The content is handled by:
```
import gi
gi.require_version('Modulemd', '1.0')
from gi.repository import Modulemd
```
or
```
import gi
gi.require_version('Modulemd', '2.0')
from gi.repository import Modulemd
```
So they do not conflict either.
Just my 2ยข.
Thanks for the questions (and the suggestion about dropping the
compat-* naming).
> Fabio
>
> > The 2.0 API is considerably more user-friendly and better documented
> > [1]. I strongly encourage any project that is consuming libmodulemd to
> > move to this new API as soon as possible. I will be maintaining the
> > 1.0 compat library through Fedora 30, but I intend to retire it from
> > Fedora 31 soon after the branch occurs.
> >
> > [1]
https://sgallagh.fedorapeople.org/docs/libmodulemd/2.0/
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org