For KDE, I built all the packages in epel8-playground. At the time, it seemed like the right thing to do. (Whether it was or not is another discussion). I also built several packages in playground that were not part of KDE, but were build and runtime dependencies.
Those non-KDE packages, I have been trying to get built on regular epel8 by their normal maintainers. Or building myself if the normal maintainer don't want to support epel8.
Question: What do I do about those package currently in -playground, that just got built in regular epel8? The versions may, or may not, be the same.
A related question, but not necessarily for this set of packages. What is our plan in a year or two, if a package clearly is maintained in epel8, but abandoned in epel8-playground?
Troy
On Fri, Nov 01, 2019 at 08:06:07AM -0700, Troy Dawson wrote:
For KDE, I built all the packages in epel8-playground. At the time, it seemed like the right thing to do. (Whether it was or not is another discussion). I also built several packages in playground that were not part of KDE, but were build and runtime dependencies.
Those non-KDE packages, I have been trying to get built on regular epel8 by their normal maintainers. Or building myself if the normal maintainer don't want to support epel8.
Question: What do I do about those package currently in -playground, that just got built in regular epel8? The versions may, or may not, be the same.
A related question, but not necessarily for this set of packages. What is our plan in a year or two, if a package clearly is maintained in epel8, but abandoned in epel8-playground?
Right, so this is what Kanarip was talking about the other day on IRC.
Consider the case:
- I have foo-1.0-1 in epel8 and epel8-playground - I want to play with foo-2.0 in playground, so I tweak packages.cfg and build it in playground. - Later I decide its stable so I build foo-2.0-1 in epel8. - A update comes out to 2.1, so I build foo-2.1-1 in epel8, but I didn't put the packages.cfg back and the version in epel8-playground is now foo-2.0-1 still. - I later try and build bar-2.0 in epel8-playground, and it builds against foo-2.0-1 instead of foo-2.1
I guess the expectation is that the maintainer should put the packages.cfg back in place when merging back to epel8, but I could see this getting forgotten.
So, perhaps the best way forward here is some reporting?
ie, check upgrade path between all epel8 and epel8-playground packages. The playgound ones should always upgrade the epel8 one.
kevin
On 11/3/19 12:47 PM, Kevin Fenzi wrote:
On Fri, Nov 01, 2019 at 08:06:07AM -0700, Troy Dawson wrote:
For KDE, I built all the packages in epel8-playground. At the time, it seemed like the right thing to do. (Whether it was or not is another discussion). I also built several packages in playground that were not part of KDE, but were build and runtime dependencies.
Those non-KDE packages, I have been trying to get built on regular epel8 by their normal maintainers. Or building myself if the normal maintainer don't want to support epel8.
Question: What do I do about those package currently in -playground, that just got built in regular epel8? The versions may, or may not, be the same.
A related question, but not necessarily for this set of packages. What is our plan in a year or two, if a package clearly is maintained in epel8, but abandoned in epel8-playground?
Right, so this is what Kanarip was talking about the other day on IRC.
Consider the case:
- I have foo-1.0-1 in epel8 and epel8-playground
- I want to play with foo-2.0 in playground, so I tweak packages.cfg and build it in playground.
- Later I decide its stable so I build foo-2.0-1 in epel8.
- A update comes out to 2.1, so I build foo-2.1-1 in epel8, but I didn't put the packages.cfg back and the version in epel8-playground is now foo-2.0-1 still.
- I later try and build bar-2.0 in epel8-playground, and it builds against foo-2.0-1 instead of foo-2.1
I guess the expectation is that the maintainer should put the packages.cfg back in place when merging back to epel8, but I could see this getting forgotten.
So, perhaps the best way forward here is some reporting?
ie, check upgrade path between all epel8 and epel8-playground packages. The playgound ones should always upgrade the epel8 one.
kevin
I guess I don't see why anyone needs to muck with packages.cfg. If you want to build something for epel8-playground, just build it from the epel8-playground branch.
It seems to be worse than that. When I tried around 2 weeks ago, building a version in epel8-playground blocked building the same version in epel8. https://pagure.io/releng/issue/8925 I did similar builds earlier and didn't have the problem.
I have packages.cfg that targets epel8 in the epel8 git branch and epel8-playground in the epel8-playground branch and haven't touched them.
Dave
On Sun, Nov 03, 2019 at 01:57:13PM -0700, Orion Poplawski wrote:
On 11/3/19 12:47 PM, Kevin Fenzi wrote:
On Fri, Nov 01, 2019 at 08:06:07AM -0700, Troy Dawson wrote:
For KDE, I built all the packages in epel8-playground. At the time, it seemed like the right thing to do. (Whether it was or not is another discussion). I also built several packages in playground that were not part of KDE, but were build and runtime dependencies.
Those non-KDE packages, I have been trying to get built on regular epel8 by their normal maintainers. Or building myself if the normal maintainer don't want to support epel8.
Question: What do I do about those package currently in -playground, that just got built in regular epel8? The versions may, or may not, be the same.
A related question, but not necessarily for this set of packages. What is our plan in a year or two, if a package clearly is maintained in epel8, but abandoned in epel8-playground?
Right, so this is what Kanarip was talking about the other day on IRC.
Consider the case:
- I have foo-1.0-1 in epel8 and epel8-playground
- I want to play with foo-2.0 in playground, so I tweak packages.cfg and build it in playground.
- Later I decide its stable so I build foo-2.0-1 in epel8.
- A update comes out to 2.1, so I build foo-2.1-1 in epel8, but I didn't put the packages.cfg back and the version in epel8-playground is now foo-2.0-1 still.
- I later try and build bar-2.0 in epel8-playground, and it builds against foo-2.0-1 instead of foo-2.1
I guess the expectation is that the maintainer should put the packages.cfg back in place when merging back to epel8, but I could see this getting forgotten.
So, perhaps the best way forward here is some reporting?
ie, check upgrade path between all epel8 and epel8-playground packages. The playgound ones should always upgrade the epel8 one.
kevin
I guess I don't see why anyone needs to muck with packages.cfg. If you want to build something for epel8-playground, just build it from the epel8-playground branch.
On Mon, 4 Nov 2019 at 18:35, Dave Dykstra dwd@fnal.gov wrote:
It seems to be worse than that. When I tried around 2 weeks ago, building a version in epel8-playground blocked building the same version in epel8. https://pagure.io/releng/issue/8925 I did similar builds earlier and didn't have the problem.
There was a problem in the build system when you tried this. I have replied to the ticket as it should be cleared up now and I thought all tickets had been answered but I missed this one.
I have packages.cfg that targets epel8 in the epel8 git branch and epel8-playground in the epel8-playground branch and haven't touched them.
Dave
On Sun, Nov 03, 2019 at 01:57:13PM -0700, Orion Poplawski wrote:
On 11/3/19 12:47 PM, Kevin Fenzi wrote:
On Fri, Nov 01, 2019 at 08:06:07AM -0700, Troy Dawson wrote:
For KDE, I built all the packages in epel8-playground. At the time, it seemed like the right thing to do. (Whether it was or not is another discussion). I also built several packages in playground that were not part of KDE, but were build and runtime dependencies.
Those non-KDE packages, I have been trying to get built on regular epel8 by their normal maintainers. Or building myself if the normal maintainer don't want to support epel8.
Question: What do I do about those package currently in -playground, that just got built in regular epel8? The versions may, or may not, be the same.
A related question, but not necessarily for this set of packages. What is our plan in a year or two, if a package clearly is maintained in epel8, but abandoned in epel8-playground?
Right, so this is what Kanarip was talking about the other day on IRC.
Consider the case:
- I have foo-1.0-1 in epel8 and epel8-playground
- I want to play with foo-2.0 in playground, so I tweak packages.cfg and build it in playground.
- Later I decide its stable so I build foo-2.0-1 in epel8.
- A update comes out to 2.1, so I build foo-2.1-1 in epel8, but I didn't put the packages.cfg back and the version in epel8-playground is now foo-2.0-1 still.
- I later try and build bar-2.0 in epel8-playground, and it builds against foo-2.0-1 instead of foo-2.1
I guess the expectation is that the maintainer should put the packages.cfg back in place when merging back to epel8, but I could see this getting forgotten.
So, perhaps the best way forward here is some reporting?
ie, check upgrade path between all epel8 and epel8-playground packages. The playgound ones should always upgrade the epel8 one.
kevin
I guess I don't see why anyone needs to muck with packages.cfg. If you want to build something for epel8-playground, just build it from the epel8-playground branch.
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@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/epel-devel@lists.fedoraproject...
epel-devel@lists.fedoraproject.org
-
Dave Dykstra -
Kevin Fenzi -
Orion Poplawski -
Stephen John Smoogen -
Troy Dawson