Björn Persson wrote:
I think the best way forward is to make three new source packages – gnatcoll-core, gnatcoll-bindings and gnatcoll-db – and turn the current gnatcoll package into a metapackage that pulls in the three new ones to make upgrades smooth.
Here's a revised plan:
Only two new source packages will be made: gnatcoll-bindings and gnatcoll-db. The source package gnatcoll will produce the subpackages gnatcoll-core and gnatcoll-core-devel, which contain the core library. The same source package will also produce the subpackages gnatcoll and gnatcoll-devel, which contain no files but pull in all the components. Thus the current gnatcoll package will remain the source package for the core library (though heavily remade), there will be one less source package to handle, and the upgrade path should be safe.
Here's my proposal for the upgraded gnatcoll source package:
https://src.fedoraproject.org/rpms/gnatcoll/blob/gnatcoll-core-2018/f/gnatco...
Pavel, how do you like this plan?
Here's a review request for gnatcoll-bindings, made in accordance with this plan:
https://bugzilla.redhat.com/show_bug.cgi?id=1689552
This package produces separate subpackages for the different bindings so that a program doesn't have to pull in Readline and GMP just because it logs through Syslog.
gnatcoll-python is excluded for now. It binds to some functions that don't exist in Python 3. I see that it's already disabled in the Gnatcoll 2017 package. A libgnatcoll_python.so.2017 somehow exists though, but it's too small to contain a Python binding. After the upgrade that file will be gone.
By the way, Gnatcoll.VFS.GTKada seems to be gone from the source, so neither of these packages depend on GTKada anymore and there won't be a libgnatcoll_gtk.
And now on to gnatcoll-db.
Björn