On Tue, Aug 13, 2019 at 5:22 AM Mattias Ellert
<mattias.ellert(a)physics.uu.se> wrote:
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
I was not aware that we were using playground for the second usecase.
I thought the discussions we had in our weekly EPEL Steering meeting
we agreed *not* to use playground for rebuilding, but had agreed to
use side-tags. If I was wrong, could someone please point me to the
document that says we do.
Honestly, the package.cfg reasoning is rather vague to me. I'm not
sure where it came from. I don't remember being asked about it.
Personally, if I had been asked I would have said that at the least,
it needs to be .package.cfg. This is done in several places in the
Red Hat Brew dist-git, and it stops alot of these types of
discussions.
But I also didn't fight against it. Why? Because I knew the first
thing I was going to do was delete it. And ... that's what I've done.
Unfortunately, the way I've deleted it (git merge f30) seems to create
a freighter boatload of emails to various people (who are not me).
But the end result is that for a majority of my epel8 dist-git repo's
are in sync with f30. Are they "perfectly" in sync? Well, I guess
according to what you define it, no, but I am able to do a "git merge
<branch>" and it merges without any issues. That's what I care about,
and I bet in the end, that's what you care about as well.
Troy