Hi! I recently had a discussion about the use of the playground on pagure.io: https://pagure.io/releng/issue/8582 I was asked to bring the discussion here to epel-devel. I quote my last comment from the thread below. If you want more details you can read the entire thread at the pagure link above. You plan is to use the epel-playground repo for two very different and incompatible tasks. The first usecase is as a playground where maintainers can try out new versions and new features. This means that the versions of packages in the epel-playground are allowed to be different from the versions in epel, might have additional features enabled that the versions in epel are missing, and occasionally could even be backward incompatible with the version i epel or have a different soname for libraries. The second usecase is as a place to do mass rebuilds for new rhel point releases, where you plan to change the rhel base to a new point release in epel-playgroind, do the rebuilds in epel-playground, and the when you change th epel repo to the new point release merge the mass rebuilt packages back to epel. But, since the use case for the playground repository was to be a place where new unstable stuff is tested, all those rebuilds will have been built against these new versions and might depend on features that are not provided by the dependencies that are in epel, or be compiled to depend on a different soname than the library that is available in epel. I.e. since the playground is a playground, packages built in the playground must never be merged into main epel. In Fedora there are rebuilds all the time. For new python versions, for new perl versions, and the recurring mass rebuilds. These are done in side tags. This can be done without adding a package.cfg file allowing the build of the package in the side tag, but koji allows this by default. The proper way to do a mass rebukd for epel8 is to declare an epel8- rebuild sidetag that inherits from the rhel 8.n+1 and epel8 and definitely must not inherit from epel8-playground. The packages built in this sidetag can then be safely merged into epel8, when epel8 is redefined to inherit from rhel 8.n+1. And since it is a sidetag there should be no need to add any special package.cfg since this is not needed for sidetags in fedora. Mattias
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
