Gnatcoll 2018

[Björn Persson]

Gnatcoll 2017 can no longer be built in Fedora 30 because of API changes
in libgpr. An upgrade to Gnatcoll 2018 is necessary, but has the
complication that Gnatcoll has been split into three separate libraries.

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. After a few releases I think we can retire the
metapackage.

As a start I have a gnatcoll-core review request here:

https://bugzilla.redhat.com/show_bug.cgi?id=1685226

I'm not yet sure about the directory layout. I may find that I need to
move some files when I make the other packages.

Björn

[Björn Persson]

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

[Pavel Zhukov]

Hi Bjorn,

LGTM.

P.S. Sorry for the delay. Gmail keeps marking your emails as spam for some
reason.

On Sat, Mar 16, 2019 at 5:58 PM Björn Persson <Bjorn@rombobjörn.se> wrote:
> 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
> _______________________________________________
> Ada mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Björn Persson]

Pavel Zhukov wrote:
> LGTM.

Then I'll go ahead and merge the gnatcoll-core-2018 branch.

Björn

[Vadim Godunko]

On 3/16/19 7:57 PM, Björn Persson wrote:
> 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.

All GtkAda packages was moved to GPS source tree, because they introduce 
unnecessary dependency from GtkAda and and seems not used by anyone 
except GPS.

[Björn Persson]

And now the third package, gnatcoll-db, is ready for review:

https://bugzilla.redhat.com/show_bug.cgi?id=1692166

It won't build in Koji until gnatcoll-bindings has been imported and
built.

After both reviews are done I'll make buildroot overrides to build the
packages for F30, and then push all the packages through Bodhi together.

Björn

[Björn Persson]

I finally found a reviewer for gnatcoll-db, and now the whole set of
Gnatcoll 2018 packages has worked its way through Bodhi. I think they
should be available on most mirrors by now.

Users of Gnatcoll can finally upgrade to Fedora 30.

Björn Persson