Re: Fedora 31 Self-Contained Change proposal: Move test.support module to python3-test subpackage

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

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux