Erick Wittman erick.wittman@gmail.com 于 2020年7月14日周二 上午11:22写道：

Hi EPEL developers.

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 cannot find a current Fedora maintainer listed for this package, but it is available in Fedora (at least in version 32).

AKAIK gcc-gnat should be a sub package for gcc, making this appear in EPEL

should be just a tweak in gcc's spec file. So, you should contact gcc's maintainer to check what to do.

Are there any EPEL maintainers who are interested in creating an EPEL version of this package?

Thank you

---

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...

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...

Thanks Stephen and Florian for your input. It's now clear that a package that only adds the "missing pieces" won't work.

Stephen John Smoogen wrote:

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

The module option seems like it would be easiest to use for the users, and would also avoid the risk that one program might invoke the wrong build of another program.

Björn Persson