On Tue, 2019-06-25 at 00:26 +0200, Miro Hrončok wrote:
> On 25. 06. 19 0:18, Yaakov Selkowitz wrote:
> > On Mon, 2019-06-24 at 23:09 +0200, Miro Hrončok wrote:
> > > On 24. 06. 19 22:25, Yaakov Selkowitz wrote:
> > > > On Mon, 2019-06-24 at 22:10 +0200, Miro Hrončok wrote:
> > > > > On 24. 06. 19 22:06, Yaakov Selkowitz wrote:
> > > > > > On Mon, 2019-06-24 at 12:09 -0400, Ben Cotton wrote:
> > > > > > >
https://fedoraproject.org/wiki/Changes/Move_test.support_module_to_python...
> > > > > > >
> > > > > > > == Summary ==
> > > > > > >
> > > > > > > Move <code>test.support</code> from
<code>python3-libs</code> to
> > > > > > > <code>python3-test</code> subpackage.
> > > > > > >
> > > > > > > == Owner ==
> > > > > > > * Name: [[User:lbalhar| Lumír Balhar]]
> > > > > > > * Email: [mailto:lbalhar@redhat.com|
lbalhar(a)redhat.com]
> > > > > > >
> > > > > > >
> > > > > > > == Detailed Description ==
> > > > > > >
> > > > > > > Python test modules should be used only for testing
Python itself.
> > > > > > > However, some packages have buildtime or runtime
dependency on parts
> > > > > > > of Python test modules. The aim of this change is to
move the most
> > > > > > > popular Python test module
<code>test.support</code> from
> > > > > > > <code>python3-libs</code> to
<code>python3-test</code> subpackage
> > > > > > > which will help us discover packages which depend on
it and also
> > > > > > > identify parts of the module which might be useful to
move to standard
> > > > > > > library.
> > > > > >
> > > > > > The main reason for this change is to *experiment* and see
what breaks
> > > > > > when it is moved? Why can't that be done in copr
instead?
> > > > >
> > > > > The main reason for this change is to make packaging of Python
easier (and more
> > > > > explicit) and less error prone in the future. Discovering
packages that need
> > > > > test.support is a secondary goal that help upstream but does not
help Fedora much.
> > > > >
> > > > > Should the change be reworded so this is more clear?
> > > >
> > > > 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 :)
Pierre