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.
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.