On Tue, 14 Jul 2020 at 07:56, Björn Persson <Bjorn@rombobjörn.se> wrote:

Erick Wittman wrote:

...

I am using CentOS 8 and am using various packages in the EPEL repository. I am interested in seeing gcc-gnat added to EPEL.

I would also like to have gcc-gnat in CentOS 8. I maintain some Ada packages in Fedora and EPEL 7 that I wish I could add to EPEL 8.

In Fedora and earlier versions of RHEL/CentOS, gcc-gnat is a subpackage of gcc. Adding it to EPEL would make it a separate package. I'm not sure what complications might arise from that.

Subpackages of gcc usually require the entire gcc tree to be rebuilt which leads to some problems. First is the spec file able to build various sub-packages. Some .src.rpms spec files have things removed which are in Fedora to make it clearer what is 'supported' by Red Hat. This clears up 'junk' which might not be wanted to ship but also can clear flags which are needed in say gcc to make gcc-gnat but would cause 'problems' in gcc-foobar.

Second, the way the Fedora Build System (koji+pdc+mbs+....) works is that the compose tree can only have 1 named src.rpm to be used to 'pull packages' from. This means that you can't rebuild gcc with the same <version>-<release> as is in the 'buildroot'. It must be greater and it will then replace that pacakge in future build roots. This means that the gcc.src.rpm with gnat turned on which is used for this would need to build all packages and then be used to build all future EPEL packages. The 'fix' would be either to make a parallel installable gcc with a different name which did not collide with gcc on install. Three example ways to do this would be: 1. Make a non-default module which contained all the rebuilt binaries needed to make gcc-gnat and other tools work (some languages also need other utilities rebuilt to work). 2. Make an SCL which contains all these. 3. Make a set of rpms which installed gcc<name> in all the same places as gcc but didn't collide

A fourth way for the private rpm would be to sort of go SCL with a package that created an approved /opt space with bin,lib etc in it say /opt/bjornspace/{bin,lib,etc} and had paths set up to that.

So far I haven't had time to even try. I suspect I won't be able to do it alone, but it might be doable if we could assemble a team of interested maintainers.

Björn Persson _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...

* Björn Persson:

In Fedora and earlier versions of RHEL/CentOS, gcc-gnat is a subpackage of gcc. Adding it to EPEL would make it a separate package. I'm not sure what complications might arise from that.

The main problem is that /usr/bin/gcc does not have Ada support. It will not try to invoke gnat1 (the actual Ada compiler) even if it is installed at the correct path. I'm trying to figure out if anything can be done about this. This change would have to happen in the gcc package.

If this change does not happen, you will have to ship /usr/bin/gnatgcc instead, with some patching of the GNAT tools to use that. Ada packages that assume a single compiler driver for Ada/C/C++ will need fixing, too.

Thanks, Florian