> I do not like it being part of epel-release, because it is (possibly) > not compatible with a regular RHEL/CentOS release. My thinking there is that shipping it as a disabled repository in epel-release makes it easier to consume in that gap between a RHEL minor release and the corresponding CentOS Linux rebuild. Imagine the scenario where an issue with an uninstallable package during that gap is solved just by running `dnf --enablerepo epel-next update`. I'm not entirely opposed to doing it as a subpackage, but it does add an extra step in the scenario I'm describing. As far as users enabling it when they shouldn't, we'll never be able to completely idiot proof things. Personally I think disabled by default is a sufficient safety measure here, but I won't lose any sleep if the steering committee insists on it being an optional subpackage. > I believe there is one other thing that was mentioned during the > meeting, and that is the lifetime. > If I remember right, the lifetime of epel8-next would only be until N > months after RHEL9 was released. (1 < N < 12) That would align with CentOS Stream, but we could keep it around for RHEL Betas and the CentOS Linux rebuild gap. Library changes are less common after the next RHEL major version is released, but they still happen. For example, in RHEL 7 ImageMagick had a library soname bump in 7.8, over six years after the initial RHEL 7 release. On Wed, Sep 9, 2020 at 8:31 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote: > > > > On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote: > > > To solve this problem, I am proposing that we create a new repository called > > > EPEL 8 Next. > > > > > > - built against CentOS 8 Stream > > > - opt-in for packagers (must request epel8-next dist-git branch) > > > - opt-in for users (part of epel-release but disabled by default) > > I do not like it being part of epel-release, because it is (possibly) > not compatible with a regular RHEL/CentOS release. > I don't mind it being a sub-package of epel-release, something like > epel-stream-repo, but not what they get when they do the basic > epel-release install. > Users have to go through extra steps to get and use CentOS Stream, > they can do an extra step to get the EPEL next repo. > > > > - used *with* epel8, not *instead of* > > > > > I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it > > is to be use with Stream, why don't we call it EPEL 8 Stream? I think the > > meaning of the repository would be easier to understand. > > > > Very good question, one I asked in the meeting. > If I got the argument right, then the amount of red-tape / legal work > it would take to call it epel-stream would be much higher than we want > to pay. > Many of us didn't like the name "Stream" to begin with since it is > sooo overloaded. > > But that also is part of the reason I don't want the repo installed by default. > If your average EPEL user were to see that there was now a repo called > epel-next, they would think it is what we currently call playground. > Where the maintainers put their next versions of things. Those users > (and I'm sure there are many) who want to test, or use the next > version of ... whatever it is ... let's say nedit, would enable > epel-next, and then be disappointed that anything in there won't > install on their system. > > I believe there is one other thing that was mentioned during the > meeting, and that is the lifetime. > If I remember right, the lifetime of epel8-next would only be until N > months after RHEL9 was released. (1 < N < 12) > > Troy > _______________________________________________ > 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 -- Carl George _______________________________________________ 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
