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:
Pavel, how do you like this plan?
Here's a review request for gnatcoll-bindings, made in accordance with
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
And now on to gnatcoll-db.
Ada mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com