On Fri, Jan 24, 2020 at 2:13 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Fri, Jan 24, 2020 at 5:08 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > > > Hi All, > > As many of you know, I'm working on a "KDE-rawhide" module for EPEL8. > > This module would build the whole KDE/Plasma/kf5/qt5 stack as a module > > for EPEL8, using what is in Fedora rawhide. > > > > As a result, I'm going to put some %if statements in some of the > > Fedora master spec files. > > > > Most of these are because of missing -devel packages from RHEL8, as > > well as some desktop related packages not being on all arches. > > > > This will affect between 30 and 60 packages. > > > > I will try to keep these as unobtrusive as I can, but also detailed in > > the git commit. > > > > One question I have. Do ya'll think I should change the release version? > > I was thinking not, since I don't plan on rebuilding these on rawhide. > > But then it looks strange if I don't have these changes in the > > changelog. > > I keep going back and forth on the release number change. > > > > It's fine to not bump the release and changelog in this circumstance. > You're not building it into master, and it can be taken care of by the > next change by who builds it then. > > That said, do you have a strategy for tracking master well with > modulemds? It doesn't seem like this handles it well.. > Perhaps I don't understand the question, but the packages in the module are pointing at the master branch, so whatever is in there is what get's built. If you mean, what if we're in the middle of a plasma/qt5/kf5 update and it tries to build that? Or people use that? Once the module is building properly, I plan on rebuilding it only once a month. This is mainly due to the EPEL two week waiting/testing process, which often takes more than two weeks. I figure at once a month, if it looks like someone is in the middle of updating a portion, I'll just wait. A few days here or there won't delay too much. If it's something else that you meant, then I missed it. Troy _______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-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/kde@xxxxxxxxxxxxxxxxxxxxxxx