On Fri, 2019-06-28 at 09:25 +0200, Lumir Balhar wrote: > On 6/25/19 12:25 PM, Miro Hrončok wrote: > > On 25. 06. 19 12:07, Pierre-Yves Chibon wrote: > > > On Tue, Jun 25, 2019 at 10:48:42AM +0200, Miro Hrončok wrote: > > > > On 25. 06. 19 9:50, Pierre-Yves Chibon wrote: > > > > > > > > > > I would say the scoping should happen (e.g. in copr) first, then we'll > > > > > > > > > > know what the scope (and hence feasibility) of this change truly is. > > > > > > > > > > > > > > > > > > What will the scoping actually tell us? If it tells us that X hundred packages > > > > > > > > > need to add BR for python3-test, we'll just do that and report the list to > > > > > > > > > upstream. We can do that during the mass rebuild. > > > > > > > > > > > > > > > > If there would indeed be X hundred packages affected, would this move > > > > > > > > still make sense? The python3-test subpackage is even larger than most > > > > > > > > of the rest of python3 combined, and the vast majority of it is > > > > > > > > irrelevant to other packages. Such usage would indicate to me that > > > > > > > > some work needs to be done within the ecosystem to respect its official > > > > > > > > status as internal-only. (Perhaps, in that case, a move to > > > > > > > > python3-devel could be considered instead.) > > > > > > > > > > > > > > Good questions. What number of affected packages do you think would be crucial? > > > > > > > I say X hundred, because I don't anticipate it will go to thousands. However > > > > > > > with 3000 Python packages, couple hundreds is IMHO not a big deal. Note that > > > > > > > this is build dependency, not a runtime one. > > > > > > > > > > > > Nevertheless, there has been a great deal of effort recently to shrink > > > > > > buildroots and speed up build times. Having to add BR: python3-test to > > > > > > packages would mean adding a download of ~9MiB and an installation of > > > > > > ~3K files to every single affected package's build time. IMO this > > > > > > needs to be fully scoped before consideration. > > > > > > > > > > Wait a minute, adding a BR python3-test would mean an additional 9MiB ok, but > > > > > currently these files are part of python3-libs which *every packages* get. > > > > > In other words, for the packages that require python3-test the amount of data > > > > > downloaded doesn't change while for all the packages that do *not* require > > > > > python3-test, the amount of data is reduced. > > > > > This sounds like a win to me :) > > > > > > > > Unfortunately, this is not correct. > > > > > > > > python3-test already is large. > > > > > > > > We just move a small bit of python3-libs (test.support) and we move it to > > > > python3-test for consistency. > > > > > > > > test.support is 396K installed (for Python 3.8). > > > > > > Arf, then it's a lesser win than I thought. > > > Have you considered doing a python3-test-support subpackage? This would allow > > > the separate package and thus give you the information you're looking for as > > > well as avoid downloading the entire python3-test for these few files. > > > > The purpose of this change is to make packaging of Python easier and > > avoid problems, when the test.support module cannot be properly used > > without the rest of the test module. What you are proposing will make > > packaging more complicated and would not eliminate the problems at all. > > > > I think we are talking about couple packages here. Would it make sense > > to have a number and say that if more than X packages suddenly need to > > add BR for python3-test, we revert the change and consider a different > > approach? > > > > BTW python3-test is now buildrequired by 7 packages: > > python-bz2file > > python-honcho > > python-iniparse > > python-kitchen > > python-typing-extensions > > python-urwid > > python-zodbpickle > > > I am bringing here some numbers which help us to understand that the > change won't affect a lot of packages. > > I've prepared a special COPR [0] where test.support module is not > available at all and then I rebuilt all Python packages. From 2952 > packages 2769 built successfully and only 182 failed. Most failures were > caused by missing dependencies (python2-), incompatible pytest or sphinx > version, etc. and only 7 packages fail to build because of the missing > test.support module. From those 7 packages, 4 already require > python3-test so there will be need to change only 3 packages after we'll > move test.support module from python3-libs to python3-test. > > [0] https://copr.fedorainfracloud.org/coprs/lbalhar/test.support_change/ Thank you for doing that. This information should be included in the Change proposal and the "help us discover" wording removed. -- Yaakov Selkowitz Senior Software Engineer - Platform Enablement Red Hat, Inc. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx