Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

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?

[Toshio Kuratomi]

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.4 for 7

[Toshio Kuratomi]

On Apr 27, 2014 9:37 AM, Aaron Knister aaron.knis...@gmail.com wrote:


 On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi a.bad...@gmail.com wrote:


 On Apr 26, 2014 8:27 PM, Aaron Knister aaron.knis...@gmail.com 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

EPEL RFC: Strategy for python3 versions

[Toshio Kuratomi]

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

EPEL Orphan or retire the TurboGears (v1) stack in 7

[Toshio Kuratomi]

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 Orphan or retire the TurboGears (v1) stack in 7

[Toshio Kuratomi]

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

Re: EPEL Orphan or retire the TurboGears (v1) stack in 7

[Toshio Kuratomi]

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

[Toshio Kuratomi]

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

[EPEL-devel] Re: Which python3 versions to package for EPEL7?

[Toshio Kuratomi]

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

[EPEL-devel] Re: Virtual packages providing python2-*

[Toshio Kuratomi]

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: ansible retired in epel7

[Toshio Kuratomi]

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: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Toshio Kuratomi]

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-core-2.11.x in CentOS stream 9

[Toshio Kuratomi]

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