On Fri, 4 Oct 2019 at 12:25, Pavel Raiskup <prais...@redhat.com> wrote: > > On Friday, October 4, 2019 10:57:05 AM CEST Fabio Valentini wrote: > > On Fri, Oct 4, 2019 at 10:47 AM Nicolas Chauvet <kwiz...@gmail.com> wrote: > > > > > > Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup <prais...@redhat.com> a écrit : > > > > > > > > On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote: > > > > > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote: > > > > > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto <ser...@serjux.com> > > > > > > wrote: > > > > > > > Hi, > > > > > > > epel 8 brings a new file called package.cfg, I strongly prefer to > > > > > > > keep > > > > > > > branches mergeable with fast forward , may we merge this into > > > > > > > master ? > > > > > > > like I did in pngquant [1] > > > > > > > > > > > > > > > > > > > It disables the normal build behavior for all non-master branches, > > > > > > so > > > > > > you don't want to do that. > > > > > > > > > > Well , I want keep my branches mergeable ! > > > > > > > > Same problem. I came across several epel8 branch requests ... and there > > > > always is some default 'package.cfg' file I don't really mind as I > > > > observed (the builds against epel8 just succeed without that). More, > > > > sometimes the README.md is added. > > > > I'm not sure about this, but I think without the package.cfg file, > > builds won't be submitted to both epel8 and epel8-playground, but only > > to epel8? This might not be what you want. > > For the packages I maintain, I'm not sure the playground is worth another > branch. So I'd personally let this work on someone else probably. Or > does the fact that I maintain epel8 imply I have to take care of > epel8-playground as well? >
The reason for wanting all epel8 packages in playground-epel8 was that we were wanting to make sure that people could rely on libfoo being in both without trying to set up layering logic. Say you wanted a package in epel8 and a newer one in playground-epel8. If we tried to layer playground-epel8 on top of epel8 with the idea that playground could replace epel8 packages.. it works in dnf. It does not work the same in koji. IN that case koji may just drop both packages from its buildroot or may choose different version from each which cause rpm problems in the mock. So the idea was to make every epel8 packages also be in playground. If you build X it can be built in epel8 and epel8-playground and then people can rely just on the playground version if they are building only for playground. In the end, this may not work at all.. and we will just tell people to stick their new stuff in a different build system which works for these sorts of smaller projects. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
