Re: What to do about old packages in epel8-playground

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


--
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@xxxxxxxx
Boulder, CO 80301                 https://www.nwra.com/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
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

[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux