[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9
I believe ansible-core includes a "dependency manager" depending on your definition. The ansible-galaxy command in ansible-core can install ansible collections so that's you can install modules that you may need. It is similar in scope to pip, rubygem, cargo, or any other of the language package installers. It does not resolve based on what modules/plugins are used in your playbooks but it will resolve dependencies between collection dependencies if needed (and those deps were properly listed). I know that Nirik has plans to get newer ansible packages into epel which provide an all-in-one experience by installing about 75 collections which give you an experience similar what was included in ansible-2.9 but I'll let him speak to how he wants to do that. -Toshio On Thu, Sep 16, 2021, 7:20 AM Josh Boyer wrote: > On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster > wrote: > > > > On 16.09.21 14:22, Josh Boyer wrote: > > > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi wrote: > > >> > > >> Just a heads up that ansible-core (the engine part of ansible) is now > in > > >> CentOS stream 9: > > >> > > >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core > > >> > > >> Note that this is the engine, you will likely want to install > > >> collections for modules and roles, etc. > > > > > > For those that might not have followed how Ansible has been > > > refactored, take a look at > > > https://www.ansible.com/blog/ansible-3.0.0-qa > > > > > > ansible-core is the lowest level of the ansible stack and does not > > > include many of the modules and plugins that those using ansible > > > engine (ansible-2.9) might be used to. As Kevin said, you will almost > > > certainly need additional modules/plugins not provided by > > > ansible-core. > > > > > > Out of curiosity > > > > Does CS9 provide additional (sub)packages to extend the functionality? > > Not generally. ansible-core has been added to CS9 in support of > System Roles only. This is analogous to how ansible is made available > in RHEL 8. System Roles will include the modules/plugins it needs to > manage the various areas of the OS, but they are not general purpose > ansible packages. > > > Right now EPEL8 provide the the full stack based on ansible 2.9. > > > > Will EPEL9 provide such packages to provide additional modules/plugins? > > > > And more a ansible question: Does ansible3 provide a dependencies > > manager as consequence now? > > I'll leave these for Kevin or someone else to answer in terms of EPEL 9 > plans. > > josh > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Tue, Jul 16, 2019, 3:48 PM Miro Hrončok wrote: > Hey, > > when RHEL 7.7 will be released, the following new components/packages will > be > provided (assuming from 7.7 beta): > > python3 - the Python 3.6 package > > > This new RHEL7 component builds several subpackages, all obsoleting the > subpackages of epel7 python36 package. > We will simply retire python36 from epel7. > > python-rpm-macros > = > > This new RHEL7 component is a drop-in replacement of python-rpm-macros > from > epel7, we will simply retire the package. python-epel-rpm-macros already > provide > the necessary macros for python34 in epel7. > > python3-setuptools > == > > This new RHEL7 component produces the python3-setuptools package that > obsoletes > the python36-setuptools package (built from the python3-setuptools epel7 > component). > > We cannot simply retire python3-setuptools from epel7, as it also builds > python34-setuptools in epel7 and there is no replacement for that in RHEL7. > > Easiest thing would be to stop building python36-setuptools and only keep > python34-setuptools in epel7, however IIRC we cannot have the same > component > name as in RHEL. If that is indeed the case, python3-setuptools needs to > be > retired and a new python34-setuptools component needs to be created in > epel7. Is > my assumption correct? > > python-pip > == > > This new RHEL7 component produces the python3-pip package that obsoletes > the > python36-pip package (built from the python-pip epel7 component). > > The python-pip epel7 component also produces python34-pip and python2-pip > (neither available in RHEL 7.7). > > If my previous assumption about components with RHEL names is correct, we > need 1 > or 2 new components for python34-pip and python2-pip - either we have each > in a > separate component or we create a new component that builds both (called > python-pip-epel maybe?). > > python-wheel > > > This new RHEL7 component produces the python3-wheel package. > > The python-wheel epel7 component produced python-wheel package (Python 2). > > The epel7 package was adapted to produce python2-wheel and python36-wheel, > however there was no successful build of this in epel7. > > If my previous assumption about components with RHEL names is correct, > we need to add a new python2-wheel component to epel7. > > > > Are my assumptions correct? > > If we indeed need new packages/components, I can help to create them, but > I do > not intent to maintain them. Any takers? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: ansible retired in epel7
On Oct 7, 2017 1:18 PM, "Neal Gompa" wrote: On Tue, Oct 3, 2017 at 12:49 PM, Kevin Fenzi wrote: > Greetings. > > Just a note for anyone looking for ansible in epel7. > > It's been retired there because with the release of RHEL 7.4 it's now > int the rhel-extras channel. > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterp rise_Linux/7/html-single/7.4_Release_Notes/index.html# technology_previews_red_hat_enterprise_linux_system_roles_powered_by_ansible > > Accordingly, you can get ansible now from rhel extras channel, or CentOS > extras repo. > > You can also get ansible rpms now from > http://releases.ansible.com/ansible/rpm/ > > Note that ansible continues to be available from epel6. > Since Ansible was added as an "unsupported dependency" for the System Roles feature, it's a bit different from other things in that it's unlikely to receive updates. Users of Ansible should probably avoid depending on the Extras version unless they're okay with no fixes to it... :/ Ansible upstream has added rpm packages for those who might get suck in that situation. It won't be exactly like the epel versions and we [upstream] haven't quite worked out all the things (like having an rpm with the repo config files in it) but hopefully it will be useful. http://releases.ansible.com/ansible/rpm/ (Official releases are packaged in the releases subdir, hopefully the other subdirs are equally self explanatory) -toshio ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
On Tue, Feb 23, 2016 at 2:00 PM, Jason L Tibbitts III wrote: > One annoying difference between packaging for Fedora and EPEL7 (and > probably older) is the fact that Python packages in Fedora are required > to provide "python2-foo" whereas many EL7 packages don't. This leads to > ifdefs and unpleasantness, and kind of complicates our ability to hide > some details behind macros. > The easiest thing to do if you want a single spec file for EPEL7 and Fedora is to Requires: python-foo rather than python2-foo. The packaging guidelines say that the python2 version of the module should provide both python-foo and python2-foo (one of those being the package name and the other a virtual provide) > As I see it, the easiest way to hide this (besides RH maintainers > updating those packages with the extra Provides:) is to add a bunch of > empty packages named "python2-foo" which have nothing but a dependency > on "python-foo". > Adding extra packages has the detriment of increasing the metadata size that has to be downloaded when depsolving. > > Even just getting python2-setuptools in would eliminate a lot of cruft. > There are, I believe, 166 packages which might need this, though we > don't have to add them all at once if that makes things more palatable. 166 packages might not be so bad... Or as you say, just doing a few high value ones like python2-setuptools might be the best of both worlds, providing compatibility for the most common cases but not adding significantly to the metadata. -Toshio ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Which python3 versions to package for EPEL7?
On Tue, Jan 05, 2016 at 08:07:22PM -0700, Orion Poplawski wrote: > So, I've started packaging up a bunch of python3 only packages for EPEL7 for > packages that were already in RHEL7. I've started by packaging the latest > version of the modules: > > python34-py.noarch 1.4.30-2.el7 epel-testing > python34-setuptools.noarch 19.2-3.el7epel-testing > > But these are much newer than the python2 versions: > > python-py.noarch 1.4.27-1.el7 > python-setuptools.noarch 0.9.8-4.el7 > > I'm afraid I was motivated by the possibilities of supporting newer python3 > code, but Matthias RUnge makes the valid point that this may cause confusion > and other problems[1]. > > What's the consensus here? > > 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1294865#c3 > Matthias Runge is correct that there will be a confusion factor. That will be especially pronounced for libraries which are used specifically for compatibility between python2 and python3 (python-six, python-backports-*, python-future if someone packages it eventually). This confusion is cut down slightly by having a different naming scheme (34 rather than just 3) for these packages than the equivalents in Fedora. However, as the naming difference is small, the amount that it helps with the confusion is also small. We would have been in a lot better place today if we had separate packaging of python2 and python3 packages in Fedora so that they were never in sync there but that's not something we can probably change now Despite the confusion, my feeling is that we want the newer versions. People who want to run python3 are willing to live more on the bleeding edge. What I've observed is that they want newer versions of libraries as well. Building packages that nobody wants to use because they are too old isn't that helpful to those who want to use the system packages for their development. For us packagers, getting applications to run on python3 frequently needs newer versions of supporting libraries due to bugfixes for python3 going into those libraries. Attempting to pin the python34 versions to the versions that ship with RHEL or in EPEL as the python2 version will quickly become a hindrance to us in those efforts as well. If we deem the confusion factor to be too great we could resort to the Debian library route and name packages with the library version number as well: python34-setuptools19, for example. But that carries its own set of problems: 1) Although we have a way (via setuptools/pkg_resources) to make both packaging of alternate modules and usage of the modules work it isn't as easy as working with modules packaged in the normal way. 2) If it's standard for us to package python34 modules as compat packages, our support burden will increase as people create packages for multiple versions of the upstream library. We (EPEL) need to figure out some policies on retiring old packages when they're no longer maintained. 3) If we're retiring unmaintained older versions of packages during the lifetime of a RHEL release then we probably need to figure out if our present method for determining the default python module (what version you get if you just do "import setuptools") is the best. The current way is basically, whichever version entered EPEL first is the default, all others are forward compat packages. -Toshio pgpGexnqv8uJu.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
On Mon, Jul 14, 2014 at 09:26:24AM +1000, Dan Callaghan wrote: > Excerpts from Toshio Kuratomi's message of 2014-07-13 03:53:19 +1000: > > Dan, would you like me to reassign the epel7 branch of all three of these > > packages to you? > > Yes we are using all three of these, in addition to the others I listed. > So please assign these to me, and I will start the unretirement process > on the others. > Done! -Toshio pgpVZGHxIL79K.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
On Fri, Jul 11, 2014 at 01:17:29AM +, Zhiwei Zhu wrote: > > For co-maintaining the TG1 stack, I would like to and will start to look > into how to do that, but I hope it could be recovered before I can really > offer any help, because our currently release is kind of blocked by this > issue. A lot of tasks, plans depend on whether TG1 would be availble on > EPEL7. We are going to discuss our platform support stuff early next week > and hope there would be some more good news then:) > It sounds like Dan would be willing to mentor you asw a comaintainer of the TG1 stack. If so, you can follow this policy: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer to get sponsored quicker. -Toshio pgpA4EwuHuuqB.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
On Fri, Jul 11, 2014 at 05:41:04PM +1000, Dan Callaghan wrote: > > I'm a little confused now though... I would have also expected these > other TG1 pieces to be on the list: > > * python-TurboMail This doesn't have a dep on TurboGears in them so my repoquery didn't pick it up. Possibly a packaging bug. I'm pretty sure that lmacken won't want to maintain this on EPEL7 either so you'll probably want to pick it up if you need to send email from the web app. > * python-tgmochikit This was my mistake... I remember asking lmacken about it but I just didn't retire it when I retired the others. > * TurboGears This was also my mistake. TurboGears isn't a dep of itself nor does it require itself... so when I went down the list of deps, I forgot to orphan it either. Oops. Dan, would you like me to reassign the epel7 branch of all three of these packages to you? -Toshio pgp_phXCiX5Pj.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
On Thu, Jul 10, 2014 at 05:39:40AM +, Zhiwei Zhu wrote: > Hi Toshio, > > I have just noticed this message after I failed to install TurboGears (v1) on > CentOS 7. > > We really need the TurboGears (v1) support via epel for el7. Migrating away > from TurboGears V1 to V2 or to other framework seems impossible for us at the > moment, though we know that we will have to migrate in future. > > Could you help to suggest what we could do to revive these packages and have > epel7 will still support TurboGears( v1 )? > Sure! Become a package maintainer and maintain the packages that have become orphaned in EPEL7. Note that you won't need to revive all of the packages -- some of those were retired because they depend on TurboGears1 (for instance, bodhi). You'll only need to revive the ones that TurboGears1 depends on (and those that your applications need). -Toshio > > -- > Best Regards > Jacky > > -Original Message- > From: epel-devel-boun...@lists.fedoraproject.org > [mailto:epel-devel-boun...@lists.fedoraproject.org] On Behalf Of Toshio > Kuratomi > Sent: Saturday, 21 June 2014 3:02 AM > To: epel-devel@lists.fedoraproject.org > Subject: Re: EPEL Orphan or retire the TurboGears (v1) stack in 7 > > On Mon, Jun 16, 2014 at 12:01:26PM -0700, Toshio Kuratomi wrote: > > > > If someone steps up to say they'll take ownership of TurboGears1 (one > > of the comaintainers or someone new), then I'll reassign these packages to > > them. > > If no one does, then I'll retire them in epel7 and ask that the > > packages be removed from the download repos before epel7 leaves beta. > > Someone can revive them later if they're interested. > > > > > > == Packages to be orphaned retired == > > * python-cherrypy2 > > * python-elixir > > * python-peak-rules > > * python-turbocheetah > > * bodhi > > * python-tgcaptcha2 > > * python-turboflot > > * python-turbokid (need to remove a spurious dep on this from > > TurboGears2) > > * python-turbojson (need to remove a spurious dep on this from > > TurboGears2) > > * python-paste-script (this one has other dependents in Fedora but none in > > EPEL7. Please speak up or revive this later if you're interested) > > > > These have now been retired. If someone is interested in them, feel free to > revive. > > -Toshio > [wargaming.net] > EgzO3mXGcK > This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or > PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient > and, therefore, may not be retransmitted to any party outside of the > recipient's organization without the prior written consent of the sender. If > you have received this e-mail in error please notify the sender immediately > by telephone or reply e-mail and destroy the original message without making > a copy. Wargaming.net accepts no liability for any losses or damages > resulting from infected e-mail transmissions and viruses in e-mail > attachment. kgzO3mXGcg > ___ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/epel-devel pgpe7ewpeSsvv.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
On Mon, Jun 16, 2014 at 12:01:26PM -0700, Toshio Kuratomi wrote: > > If someone steps up to say they'll take ownership of TurboGears1 (one of the > comaintainers or someone new), then I'll reassign these packages to them. > If no one does, then I'll retire them in epel7 and ask that the packages be > removed from the download repos before epel7 leaves beta. Someone can > revive them later if they're interested. > > > == Packages to be orphaned retired == > * python-cherrypy2 > * python-elixir > * python-peak-rules > * python-turbocheetah > * bodhi > * python-tgcaptcha2 > * python-turboflot > * python-turbokid (need to remove a spurious dep on this from TurboGears2) > * python-turbojson (need to remove a spurious dep on this from TurboGears2) > * python-paste-script (this one has other dependents in Fedora but none in > EPEL7. Please speak up or revive this later if you're interested) > These have now been retired. If someone is interested in them, feel free to revive. -Toshio pgpfjE71f6utj.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Orphan or retire the TurboGears (v1) stack in 7
Since RHEL7 has been released, EPEL7 won't be far behind. Before we get there, I'm planning to retire the TurboGears (v1, not Turbogears2) stack in epel7. In Fedora Infrastructure we are planning to migrate away from TurboGears1 rather than continue maintaining it throughout EPEL7's lifetime. If someone steps up to say they'll take ownership of TurboGears1 (one of the comaintainers or someone new), then I'll reassign these packages to them. If no one does, then I'll retire them in epel7 and ask that the packages be removed from the download repos before epel7 leaves beta. Someone can revive them later if they're interested. Let me know soon -- I'm planning to retire the packages no one says they're interested in maintaining at the end of this week so that they don't accidentally sneak into EPEL7 with no active maintainance. == Packages to be orphaned retired == * python-cherrypy2 * python-elixir * python-peak-rules * python-turbocheetah * bodhi * python-tgcaptcha2 * python-turboflot * python-turbokid (need to remove a spurious dep on this from TurboGears2) * python-turbojson (need to remove a spurious dep on this from TurboGears2) * python-paste-script (this one has other dependents in Fedora but none in EPEL7. Please speak up or revive this later if you're interested) Full lists of deps found (you don't need to read this unless you want to see what other packages are in the dep tree that won't be touched by this): == Found TurboGears Deps == === Requires: TG === Retire these bodhi-server-0:0.9.8-2.el7.noarch python-tgcaptcha2-0:0.2.0-5.el7.noarch python-turboflot-0:0.7.0-4.el7.noarch === BR: TurboGears === Retire these (same set as Requires: TG) bodhi-0:0.9.8-2.el7.src python-tgcaptcha2-0:0.2.0-5.el7.src python-turboflot-0:0.7.0-4.el7.src === TG Requires === Not needed by anything else python-cherrypy2 python-elixir >= 0.6.1 python-peak-rules python-tgmochikit python-turbocheetah >= 1.0 python-turbojson >= 1.3 Maybe not needed by anything else # TurboGears2? :: python-turbokid >= 1.0.5 Is this a spurious dep? # ? :: python-paste-script >= 1.7 Nothing requires or BuildRequires this but maybe it's a needed thing for the paste stack? Do not retire these # TurboGears2 :: python-tw-forms >= 0.9.6 # RHEL :: python-configobj >= 4.3.2 # RHEL :: python-dateutil # RHEL :: python-webtest # RHEL :: python-nose >= 0.9.3 :: # RHEL :: python-setuptools >= 0.6c11 # python-sqlobject, python-tw-forms :: python-formencode >= 1.2.1 # TurboGears2 :: python-genshi >= 0.4.4 # Needed by repoview, python-turbokid :: python-kid # Probably an optional dep of SQLAlchemy python-psycopg2 # fedmsg, python-fedora, many others :: python-simplejson >= 1.9.1 # mirrorbrain-tools, python-mb :: python-sqlobject >= 0.10.1 # TurboGears2, python-tw-forms :: python-toscawidgets >= 0.9.6 === TG BR === Not needed by anything else python-cherrypy2 python-elixir python-peak-rules python-tgmochikit python-turbocheetah python-turbokid >= 1.0.5 Maybe not needed by anything else # ? :: python-paste-script Nothing requires or BR's this but maybe it's a primary portion of hte paste stack? # TurboGears2? :: python-turbojson Is this a spurious dep? Do not retire dos2unix python-configobj python-dateutil python-formencode python-genshi python-kid python-nose python-setuptools python-simplejson python-sqlalchemy python-sqlobject python-tw-forms python-webtest python2-devel python-toscawidgets -Toshio pgpOpiH7HxRaE.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RFC: Strategy for python3 versions
On Tue, Apr 29, 2014 at 07:22:40PM -0600, Orion Poplawski wrote:
>
> So, I want to be explicit as to how we handle python3 modules in EPEL.
> Originally I was hoping we could simply have python3.4 provide
> python3 and maintainers could branch their current Fedora python
> modules for epel7 and build as is resulting in python3-module packages
> as in Fedora.
>
> However, I don't see how we transition easily to the next python3
> release. I suppose we could do a side tag and rebuild everything then
> have a flag day release. Does this seem workable (I don't think so)?
>
I agree, this doesn't seem workable.
> If we're going to require having python34-module packages are we going
> to require new reviews, or can we simply have people name them with
> %package -n python34-module in the epel7 branch? Would we have people
> maintain multiple versions at a time in a package? This seems like
> the workable version. I'm afraid that requiring new review all the
> time will be a serious impediment.
>
> We'll have %{__python34} etc macros then too.
>
I hadn't thought about doing things that way but it sounds pretty
attractive. There are two things that I'm not sure about:
* How do we handle updating the version of a module between python3.N and
python3.N+1?
- Perhaps we violate the 1 upstream tarball per-package rule and have one
tarball for python-3.N and a second tarball for python-3.N+1? I think
doing this would have the same drawbacks as we normally think of for
this case: we'll have to make updates to only one of the tarballs and
that will cause new binary rpms to be created for both of the
subpackages. So users will have to download packages with no changes.
I think we need to figure out a better solution to this problem.
* How does this interact with Fedora and RHEL/EPEL python modules?
- We probably don't want to share spec files with the main Fedora python
modules (those will build a single python2 and a single python3 module
from a single tarball so they're very different) or the RHEL python
modules (those will build a single python2 module from a single
tarball).
- So we probably need a different package namespace. Since RHEL6/7
doesn't have python3 we could use python3-foo for srpms and create
python3.N-foo subpackages for the binary rpms. Do we need to worry
about this clashing with packages in Fedora space at all?
+ We wouldn't want Fedora bugzilla to get these package names: maybe we
have to talk to scm admins about creating packages with no rawhide
branches [to prevent the pkgdb-bugzilla sync scripts from creating
a bugzilla entry for them in Fedora]
+ Sometimes upstreams produce a python3 module as a separate tarball
from the python2 version. In those cases, Fedora would have
a separate python3-foo srpm package since it would follow the
one-tarball-per-package "rule". We could simply re-use the srpm
package name without re-using the spec file. EPEL is probably
different enough from Fedora that this isn't a problem.
If the problem is re-review (and not maintaining multiple packages) an
alternative might be to short-circuit the review process for these packages.
We can specify in EPEL guidelines that these packages can be reviewed for
differences from the previous EPEL module version rather than a full review.
This is somewhat similar to the package rename case in Fedora which hasn't
been a major bottleneck there but it isn't a problem on the same scale as
we're talking about here. I think if we could solve the above issues,
a single package would make more sense.
>
> I like the plan of supporting 2 versions at a time. I'm willing to
> defer deciding on what the next version should be till later. Perhaps
> 3.5 won't be all that compelling and we'll want to wait for 3.6.
>
> Finally:
>python34-3.4
This has precedent.
> or python3.4-3.4
When I create new compat packages, I like to put dots in the version so
this works for me as well.
> or python-3.4-3.4
I dislike dashes in that position as it makes it hard to read.
> or python3-3.4-3.4?
I still dislike dashes but I can see how this would make logical sense if
we name module srpm packages python3-foo and module binary rpm packages as
python3-3.4-foo. If we name the modules packages python3-foo.src.rpm and
python3.4-foo.noarch.rpm, though, then I'd rather use one of the dash-less
versions above.
> Keep provides python(abi) = 3.4?
>
I think so. This is what the python3 package in Fedora does and what the
python26 package in EPEL5 does. It hasn't caused problems in those places.
I think that it means what we intend to say.
-Toshio
pgpo1wI4A2WLP.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL RFC: Strategy for python3 versions
Hi guys, Orion has submitted a python34 package for EPEL and I'm going to review them soon if no one beats me to it. In parallel with getting that approved I'd like to ask about the general strategy we'd like to take with maintaining python3 in EPEL. Python3 is an evolving language. New 3.N releases bring new features, bugfixes, and both backwards compatibility breaking and backwards compatibility enhancing changes (For instance, 3.3 brought the ability to mark regular text strings with the "u" prefix to match with python2.x. 3.5 will bring back formatting methods for byte strings.) Currently, there are a good many python libraries that work with both python2 and python3 but few libraries and few applications that are python3-only. Upstream, python3 releases generally see 18 months of bugfix updates and 5 years of security fixes[1]_. As Orion has pointed out, it would be hard for us to maintain a python3 release past upstream's EOL date as there's a lot of code in a python3 package (Not to mention the stack of packages that we'll build on top of it.) In addition, I am a little worried about the amount of time we may end up having to devote to keeping multiple python3.N packages (and stacks of packages for them) alive if we only retire old python3 releases when upstream ceases to provide support for them (back of the envelope calculations are that if we don't skip any python3.N releases, we'd be attempting to maintain 4-5 python3 releases before the first of those EOL's upstream). I'd like to propose that we attempt to maintain 2 python3 releases at any one time. We'll create python3.4 now. When python3.5 comes out in 18 months (less since python3.4 has been out for several months), we'll package that in addition. When python3.6 comes out (3 years), we'll package that and retire python3.4. Pluses: * This gives users some time to verify that their homegrown applications continue to work with the newer python3 package that we produce before the old one goes EOL. * This means that we're only working on 3 versions of python3 at a time (the two we expect users to use and the next version that we're tracking as upstream works on finishing it). * This gives us a chance to update frameworks, libraries, and other stacks of software built on top of python3 at the same time as we create the new interpreter package. So you could get python3.4 with Django-1.6.x and you could get python3.5 with Django-1.8.x Negatives: * Users will have to reverify and port apps written against python3 to the new interpreter version sometime in the 3 year lifespan of the python3 package they originally wrote it against. * Package maintainers who are creating packages that run on python3 will need to submit new packages for python3.4, python3.5, etc. * Users may have to port to both new versions of python3 and to new versions of some libraries they depend on (because we took the opportunity to update those libraries for the new python3 interpreter stack). Precedents: * With mediawiki, we now ship versioned packages and retire the old versions when upstream stops shipping updates. The stacks of packages built on top of mediawiki have to be produced for each mediawiki version. Alternatives: * Never retire the python3 packages. This leaves us trying to support the release once upstream stops support. Since new python3 releases are in demand, we'd probably end up trying to maintain all of the python3 releases that came out between when RHEL-N was released and when RHEL-N+1 releases (because maintainer focus usually shifts to building packages for RHEL-N+1 then). * Retire the python3 packages when upstream stops support. This defers the pain for users (They can use a python3.N version for about 5 years instead of about 3 years). However, it means that we're maintaining 4-5 versions of python3 at a time instead of 2-3 What do people think? Is this something we can do within the policies of EPEL? Does it make sense to go forward with this? Is it better to go with one of the alternatives? .. [1]_: Previous versions of python3 have a lifespan defined in their PEP. For instance, this one for python3.3: http://legacy.python.org/dev/peps/pep-0398/#lifespan The lifespan for the previous versions are the same: * bugfix updates for python3.N approximately every 4-6 months for approximately 18 months. * After the release of python3.N+1, a final bugfix of python3.N is released. * After that, security updates (source only) will be released until 5 years after the initial release of 3.N. 3.4 doesn't have this lifespan section but that's probably an oversight (I can ask Larry Hastings to clarify that if need be). -Toshio pgpD0KdHyh6Gn.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3.4 for 7
On Apr 27, 2014 9:37 AM, "Aaron Knister" wrote: > > > On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi wrote: > >> >> On Apr 26, 2014 8:27 PM, "Aaron Knister" wrote: >> > >> > We use both EPEL and SCL in my org. I didn't see this addressed in the email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :) >> >> If red hat does the right thing and namespaces their scl packages then there shouldn't be any conflicts. Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system. >> >> -Toshio > > The contents are namespaced but the package names are not. We'll end up with a package called python34 in each repo that are incompatible. Exactly. That's why red hat has to do the right thing. -Toshio ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3.4 for 7
On Apr 26, 2014 8:27 PM, "Aaron Knister" wrote: > > We use both EPEL and SCL in my org. I didn't see this addressed in the email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :) If red hat does the right thing and namespaces their scl packages then there shouldn't be any conflicts. Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system. -Toshio ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3.4 for 7
On Apr 26, 2014 11:37 AM, "Orion Poplawski" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/18/2014 10:53 AM, Kevin Fenzi wrote: > > On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski > > wrote: > > > >> So, we're just about ready to have python3-3.4 built in rawhide. > >> This package builds fine in EPEL7 too. So, I'm proposing to > >> build (and hopefully with help from others) maintain python3-3.4 > >> for EPEL. Other options/considerations: > >> > >> - We could build a python34-3.4 which provides python3 = 3.4. > >> This wou>>> > > Perhaps as time goes by, it may make sense to package a > > later python3.X version if people really want to.ld allow > > us to have multiple > >> versions concurrently and to conceivably eventually switch a > >> later version as the default. Not as easy to maintain as just > >> another branch of the python3 package though. And we could do a > >> hard cut at some later point with the python3 package method as > >> well, so I'm not sure it buys us much there either. > > > > I'd definitely prefer to try and do something where we aren't > > stuck with 3.4 for the rest of epel7's life. > > > >> - I looks like RedHat has been producing python33 SCLs, and > >> presumably will produce a python34 SCL eventually. Do we care > >> about this? Personally I really want to simply be able to build > >> my current Fedora python packages on EPEL7 with python3 versions > >> just as it is done in Fedora and I don't think we can do with > >> SCLs. > >> > >> So, my preference is for the first and will start that soon > >> unless there is consensus for a different approach. > > > > I think a number of fedora infrastructure folks might have input > > here, but they are all out at pycon this week... so if you could > > hold off until next week at least and I will see about pointing > > them to the thread here? > > > > kevin > > Any further thoughts on this? I *think* with either python3 as 3.4 or > python34 providing python3 = 3.4 you could later ship python35 > providing 3.5, but perhaps it would be cleaner to start with python34. > I confess to being lazy and not wanting to submit a new python34 > package for review and have to maintain it in a separate git repo. > I'm on vacation for a few days longer (fly home on Monday). I'd like to see us do a python3.4-3.4.x and then python3.5-3.5.x, etc. But that's motivated by not wanting to maintain a specific python3 package for the life of rhel/epel. I'd rather we maintain two major versions at any one time so that people have a chance to transition their code but also limiting how many versions we'd have to maintain by rhel eol. The versioning scheme would be similar to the mediawiki packages in epel for this scheme. > One interesting change from RHEL7 beta->rc is the dropping of libdb4 > which python3 currently BRs, although I cannot see any evidence in > http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x86_64/build.log > of python3 actually using it (it seems to be using gdbm instead). > Python 3 does use libdb although I think it can use libdb5. Python has a standard library that includes both libdb bindings and gdbm bindings. (note, I likely won't reply again until tuesday when I get back from vacation but please feel free to ping me on irc or send email to get my attention then. I want to achieve similar end goals as you, I'm just busy doing vacation-y, non-internet things until then.) -Toshio ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Dependency broken for TurboGears-1.1.3-8.el7.noarch
On Mar 13, 2014 10:57 PM, "Zhiwei Zhu" wrote: > > Hi Paul, > > > > Thanks for sharing this. It seems there is no straightforward solution for this kind of issue. > > > > It seems there is some kind of intersection between epel and pip. Take TurboGears for example. epel7 does provide the rpm of TurboGears but doesn’t guarantee it could be installed (epel5 didn’t have this issue, not sure for epel6). This is also applicable to TurboGears2 on epel7 which is supposed to be not old. Then I am not sure why we have TurboGears on epel7? I thought all the rpms on epel were supposed to be able to be installed, but I might be wrong. > > > > I have just installed TurboGears using pip (current TurboGears on pip is version 1.5.x). Probably we consider migrate our project to TurboGears 1.5.x or even TurboGears2. I maintain tg1 (the turbogears package) in epel6. I'm very interested in not maintaining it for epel 7. It's currently Been branched to the beta epel 7 repo because it's a dependency of python-fedora which is needed to get fedpkg working on epel 7. Before epel 7 comes out of beta I need to figure out with the rest of the fedora infrastructure team what to do about that. One option is that we'd drop the tg1 portions of python-fedora in our epel 7 package and remove tg1. If we think we can migrate or code away from tg1 in a timely manner this is likely what I'll push for. Someone else can, of course, pick up maintenance of the tg1 stack of they need it. -Toshio ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Bringing goocanvas to 7
On Mon, Jan 27, 2014 at 02:11:46PM -0500, Eric H. Christensen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > I see that goocanvas has been orphaned for EPEL-5 and EPEL-6. I need > goocanvas for a package I'm trying to bring into EPEL-7. Do I need to > pick up the EPEL-6 version or can I just start with EPEL-7? > You do not have to pick it up in the releases you do not care about. So it's fine to just pick it up in epel7. -Toshio pgpwb5RzQhTcm.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Fri, Jan 17, 2014 at 01:57:18PM -0500, Matthew Miller wrote: > On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote: > > > Packages for Infrastructure and Clouds, I think). I was thinking about > > > this > > > more recently in the context of "things we need for Fedora.next in the > > > coming year or so". The new repo might target both EL and Fedora and > > > provide > > > alternative versions maintained on, say, a 3-year lifecycle. > > Yeah -- I think that something like this could be good. A repo with > > a 3 year lifecycle may make sense for RHEL more than Fedora as the > > basesystem we're building on is still active at the end of that period. > > I'm thinking here about SCLs (or possibly other stack/env tech) that might > target current supported Fedora but have a longer lifecyle of its own (with > best-effort compatibility for three years). > > I keep coming back to this idea because it's what people ask me for. :) > Ah I see. I think present thinking around SCLs has revolved around lifetime for indivudal SCLs but having a repository wide lifetime could be either better or a useful additional guarantee. -Toshio pgpC7ZOTAYkVO.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Fri, Jan 17, 2014 at 10:55:09AM -0500, Matthew Miller wrote: > On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote: > > > system.so we've mostly decided that things in the system shouldn't use > > > SCLs > > > to work. So we still need to solve the problem of newer python > > > interpreter > > > and newer django framework for use with apps that EPEL ships. > > What about having a separate EPEL repo for SCLs and/or these newest version > > of things? Like you mentioned before, this takes more work, but if then > > those that want the stable base can have it and those that want the newest > > can have it as well. > The problem I'm raising is that SCLs don't solve the problem that sgallagh is wanting to address by current policy. He has applications (ReviewBoard) that need newer versions of a framework (django) in order to run. For us to ship reviewboard in EPEL, we'd need to figure out if we want to allow that and how. Possible options are: * ReviewBoard is in its own SCL. The SCL deps on the appropriate django SCL. * ReviewBoard is not in an SCL and we allow mainstream packages to dep on SCLs. We need to figure out guidance on how a package can enable an scl for its own use as well. Either of these may exacerbate the problem of an enabled scl polluting other applications (especially hard if we get into invoking other processes from that application... env variables like LD_LIBRRY_PATH will probably get passed onto the invoked process). > Or possibly an additional sub-project separate from EPEL. The idea has been > kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra > Packages for Infrastructure and Clouds, I think). I was thinking about this > more recently in the context of "things we need for Fedora.next in the > coming year or so". The new repo might target both EL and Fedora and provide > alternative versions maintained on, say, a 3-year lifecycle. > Yeah -- I think that something like this could be good. A repo with a 3 year lifecycle may make sense for RHEL more than Fedora as the basesystem we're building on is still active at the end of that period. pgpRdL8QZ1AjJ.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote: > > Wouldn't this be a perfect use case for Software Collections? > > http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/ > Software_Collections_Guide/index.html > I was considering this earlier and I'm a bit conflicted about that. There's several problems with this. The most obvious is that SCLs are rather coarse grained and we want to solve this for both the coarse grained stuff like (python interpreter) and fine grained things (like upgrading a single library) The second problem is that we don't just want these things for users to use. We also want them for our own use. But SCLs are meant to be isolated from the system.so we've mostly decided that things in the system shouldn't use SCLs to work. So we still need to solve the problem of newer python interpreter and newer django framework for use with apps that EPEL ships. -Toshio > -Dave > > > > > On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen wrote: > > On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi > wrote: > > > > On Jan 16, 2014 1:08 AM, "Matthias Runge" > wrote: > > > > On 01/15/2014 04:32 PM, Stephen Gallagher wrote: > > > > > > > > So my suggestion would be that EPEL should have two branches for > EPEL > > > 7: the epel7 branch and the epel7-pending branch. The idea of this > > > second branch would be sort of an EPEL Rawhide, where major > upgrades > > > can be staged. Then, when RHEL releases a minor update (such as > RHEL > > > 7.1), we have a (one-month?) integration period where we ensure > that > > > packages in epel7-pending work on the newest minor release and > then > > > they are merged back to epel7. If they miss this merge window, > they > > > have to wait until the next minor release. > > > > > > This allows us a regular, planned ability to move to newer EPEL > > > packages, without destabilizing EPEL in general. > > > > > > In order to not make this a willy-nilly breakage every six months, > we > > > might want to set some limits (or at least guidelines) on what is > or > > > is not allowed to upgrade at the minor release. But I'd be fine > with > > > deferring making such decisions until we have a demonstrated need > > > (i.e. fix it only if packages/EPEL is actually breaking). > > Interesting idea, I like that. > > > > This would be a place to put e.g django-1.6. > > > Although I would favor being able to deprecate one version of a > package > and introduce a newer incompatible version in some manner I have to > point out here that if we "set some limits" to avoid breaking things > then those limits would almost certainly cover frameworks and language > stacks like python and django. > > This is the basic problem that we inevitably face - people who have > deployed software that relies on the old version inevitably do not > want > a new, incompatible version to appear in the reps that causes them to > have to do extra porting work. People who have not yet deployed (or > written) their software want the latest and greatest version of the > software so they can build it using features provided by the latest > version. > > I think there's two classes of upgrade policy that we might implement > to address this. > > 1) we think we have enough manpower in epel to support more packages. > If this is the case then we should be looking at ways to support more > than one version of packages on the repository. Ideas here include: > > + parallel versions (what we do today. Parallel installable Python3.3 > and python3.4 packages are in this vein). > > + multiple versions that have explicit conflicts between them. > Conflicts aren't allowed in fedora packages but this could be an epel > difference. > > 2) we don't feel we have the manpower to support multiple versions. > In > this case we have to decide whether we are more strongly in favor of > supporting existing deployments or supporting new deployments. > Existing deployments is our default now. Our story for new > depl
Re: EPEL Python 3 for 7?
On Jan 16, 2014 1:08 AM, "Matthias Runge" wrote: > > On 01/15/2014 04:32 PM, Stephen Gallagher wrote: > > > > > So my suggestion would be that EPEL should have two branches for EPEL > > 7: the epel7 branch and the epel7-pending branch. The idea of this > > second branch would be sort of an EPEL Rawhide, where major upgrades > > can be staged. Then, when RHEL releases a minor update (such as RHEL > > 7.1), we have a (one-month?) integration period where we ensure that > > packages in epel7-pending work on the newest minor release and then > > they are merged back to epel7. If they miss this merge window, they > > have to wait until the next minor release. > > > > This allows us a regular, planned ability to move to newer EPEL > > packages, without destabilizing EPEL in general. > > > > In order to not make this a willy-nilly breakage every six months, we > > might want to set some limits (or at least guidelines) on what is or > > is not allowed to upgrade at the minor release. But I'd be fine with > > deferring making such decisions until we have a demonstrated need > > (i.e. fix it only if packages/EPEL is actually breaking). > Interesting idea, I like that. > > This would be a place to put e.g django-1.6. > Although I would favor being able to deprecate one version of a package and introduce a newer incompatible version in some manner I have to point out here that if we "set some limits" to avoid breaking things then those limits would almost certainly cover frameworks and language stacks like python and django. This is the basic problem that we inevitably face - people who have deployed software that relies on the old version inevitably do not want a new, incompatible version to appear in the reps that causes them to have to do extra porting work. People who have not yet deployed (or written) their software want the latest and greatest version of the software so they can build it using features provided by the latest version. I think there's two classes of upgrade policy that we might implement to address this. 1) we think we have enough manpower in epel to support more packages. If this is the case then we should be looking at ways to support more than one version of packages on the repository. Ideas here include: + parallel versions (what we do today. Parallel installable Python3.3 and python3.4 packages are in this vein). + multiple versions that have explicit conflicts between them. Conflicts aren't allowed in fedora packages but this could be an epel difference. 2) we don't feel we have the manpower to support multiple versions. In this case we have to decide whether we are more strongly in favor of supporting existing deployments or supporting new deployments. Existing deployments is our default now. Our story for new deployments is that we must have parallel installable versions to make that use case work. Sgallagh's proposal turns that around so that we favour new deployments' needs more than existing ones. There are ways to improve it for existing deployments - for instance we could create a new repository for each of these point releases. Those repositories could be open or closed for new packages/updates depending on how much manpower we think we have to throw at the problem. -Toshio ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Python 3 for 7?
On Tue, Jan 14, 2014 at 09:13:12PM +0100, Jochen Schmitt wrote: > On Tue, Jan 14, 2014 at 12:35:00PM -0700, Stephen John Smoogen wrote: > > > 1) Does providing python-3.4 mean that 3.4 will be the only python every > > provided by EPEL? > > On Fedora ew have a python package which points to the 2.7 series and a > python3 package which points to the 3.3 series of python. I think we > should take this solution for EPEL because I think that python-2.7.x is > the standard python version which should not been overriden. > > > 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going to be > > handled? > > I think we need a conservative update handling to avoid incompatibilities > caused due an python update. > We could also take the python2.6 package in EPEL5 as inspiration here and ship a python3.4. This would allow us to ship a python3.5, python3.6, etc set of packages in the future. -Toshio pgph0RCvaj5ko.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
