Dne 24. 03. 20 v 11:43 Tom Hughes via devel napsal(a): > On 24/03/2020 09:32, Aleksandra Fedorova wrote: > >> ELN is an evolution of the request for an alternate buildroot for >> newer x86_64 processors. The reasoning behind that new buildroot was >> that we expected that the next major release of RHEL would likely drop >> support for older hardware and therefore could take advantage of >> enhancements and processor extensions available for newer hardware. As >> plans for this proceeded, they expanded into a desire to do more than >> just test out the processor architecture. Instead, we want to have a >> complete alternative compose of Fedora Rawhide that resembles the way >> that Red Hat and CentOS builds their packages. The idea being that >> Fedora developers and third-party vendors who rely on Red Hat >> Enterprise Linux have a place where they can directly contribute to >> what will eventually become the next RHEL. > > For those of us who know little about the details of RHEL and CentOS > can you elaborate on what is different in the way that they build their > packages compared to Fedora? The attempt to explain this was in the following paragraph you have trimmed: > What we want to do is establish a set of RPM conditionals that can be used for the set of packages that may need to be built differently for a RHEL-like target as compared to a Fedora one. (For example, we may want to skip regenerating documentation during package-build and instead use pre-built docs from the tarball or SRPM.) One of the main concerns are package dependencies, RHEL is lets say ~4000 SRPM. But if you just take the same RPMs from Fedora, it would pull in additional dependencies. So for RHEL, we typically trim dependencies such as bindings for various languages, associated tests, test frameworks, documentation tools, etc. > >> * Other developers: >> *: Anyone who wants to produce different content for the ELN compose >> will need to implement the new macros in their specfile. The >> overwhelming majority of packages will require no modification. > > What is the impact on "other developers" who don't want to do those > things? Is there an expectation that Fedora packagers will make any > necessary changes to ensure their packages build in this environment > and continue to respond to issues to keep them building there? I am not the change owner. However, I believe that there is not definitive answer to this question and part of the challenge is to find the answer. Believe it or not, although I maintain packages in RHEL, I don't want to see Fedora packages polluted with conditionals, so I hope there will be some "overlay" git branch, allowing to `git rebase` packages from Fedora. Others will be in favor of the conditionals. I don't see this different then the current discussion if we should merge branches between Fedora versions and keep conditionals for RHEL/EPEL or not. Vít > > > Tom > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
