On 2/13/20 02:21, Tomas Orsava wrote: > On 2/13/20 5:18 AM, Orion Poplawski wrote: >> On 1/30/20 8:39 AM, Miro Hrončok wrote: >>> On 30. 01. 20 16:32, Orion Poplawski wrote: >>>> Folks - >>>> >>>> Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. From >>>> the 8.2 beta: >>>> >>>> Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs) >>>> Name Stream Profiles Summary >>>> python27 2.7 [d][e] common [d] Python programming >>>> language, version 2.7 >>>> python36 3.6 [d][e] build, common [d] Python programming >>>> language, version 3.6 >>>> python38 3.8 [d][e] build, common [d] Python programming >>>> language, version 3.8 >>>> >>>> Currently, %python_pkgversion is set to 3 in >>>> /usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros. >>>> >>>> python3-devel is still provided only by python36-devel, so presumably all >>>> EPEL8 python packages will continue to be built against python 3.6. But I >>>> imagine that people will soon be asking for python 3.8 versions of EPEL >>>> packages. How can we provide those? Does this have to be done in some >>>> modular fashion - which seems to come back to the discussion of whether or >>>> not >>>> every package has to become its own module or whether to group them together >>>> somehow. Or since both python modules are "default" modules and we can >>>> install both python36-devel and python38-devel at the same time, perhaps we >>>> can define the python3_other* macros again for python38 and just go that way? >>>> >>>> Thoughts? >>> >>> The idea is that the versions fo stuff we build in RHEL for different >>> python versions is different and I'd like to keep that idea in EPEL as >>> well. Building a python38-foo package from it's own spec should work as >>> follows: >>> >>> BR python38-rpm-macros >>> BR python38-devel >>> BR python38-bar etc... >>> >>> Regular specfile follows. >>> >>> You can even have a single specfile that build for different Python version >>> based on local override of %python_pkgversion in the buildroot. >>> >>> Building both versions from single spec file---single build would require a >>> new set of macros, yes (or hardcoding stuff). However I'd not call them >>> python3_other* unless you want to end up with python3_other_other* the next >>> time this happens. >>> >> >> This along with some more info from rhel 8.2 beta yields more questions for >> me. While I do agree that building the python38 packages from separate >> specs probably is the best route (biggest reason being it allows for >> updating of individual module versions) I'm hoping we can brainstorm ways to >> make this less onerous on individual packagers. >> >> Looks like python38-devel is a module in RHEL 8.2 that provides a bunch of >> stuff needed for building modules (python38-devel, python38-pytest, etc): > > > Hi! > Just a little correction, despite the name suggesting otherwise, the > "python38-devel" package is not in the python38-devel module, but in the > python38 module itself, which has a default stream. > > The python38-devel module contains only python38-pytest and it's dependencies > (pyparsing, atomicwrites, attrs, packaging, py, more-itertools, pluggy, > wcwidth). And the reason it's not default is not an intention but a current > technical limitation of the automatically generated "-devel" modules shipped > in the CRB. > > >> >> Red Hat CodeReady Linux Builder Beta for RHEL 8 x86_64 (RPMs) >> Name Stream Profiles Summary >> python38-devel 3.8 [e] Python programming >> language, version 3.8 >> >> Since this isn't a default module, does this again mean the python38 >> packages in EPEL 8 need to be modules as well? Or can we provide a >> buildroot that enables this module? >> >> My current pie-in-the-sky idea is that we could do: >> >> - create a epel8-python38 branch for all of the python-* packages with epel8 >> branches. >> - epel8-python38 buildroot would enable python38-devel and install >> python38-rpm-macros and define python3_pkgversion to 38. >> - This would imply an epel8-python38 repo. It's possible that some packages >> from epel8-python38 wouldn't be able to be installed unless the >> python38-devel module was enabled. >> - This might lead to an explosion of repos if we try to work around other >> modules in RHEL8 like this (php 7.3, perl, ruby 2.6) >> >> >> Otherwise I think we will need python38 packages in EPEL8 to be modular. If >> the module route is the way to go, I really do think that we should try to >> not have every package be its own module, though the other extreme (all >> packages in one module) probably is untenable as well. In any case, this >> will require a lot more coordination among packagers (not necessarily a bad >> thing). >> >> Thoughts? Plans? > > > Since pytest is usually a build dependency, then theoretically you could have > non-modular python38 packages in EPEL, since all the important stuff is in > python38 with a default stream. > > Tomas Except that we are going to need python38-pytest, etc. in the EPEL8 buildroot if we are going to build (most of) the packages in the first place. That's the problem I'm running into now trying to build python38-jmespath: https://koji.fedoraproject.org/koji/taskinfo?taskID=83570866 DEBUG util.py:444: No matching package to install: 'python38-pytest' So I'm back to my original questions: * Do we just make EPEL python38- packages as modules or try to hack up some kind of build system support for it? * If modules, every package a module or one (or a few) modules? -- Orion Poplawski IT Systems Manager 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
