Bug 1637959

Summary: Separate the test directory as python37-test
Product: [Fedora] Fedora Reporter: Jun Aruga <jaruga>
Component: python37Assignee: Miro Hrončok <mhroncok>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: cstratak, mhroncok, pviktori
Target Milestone: ---Keywords: FutureFeature, RFE
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-11-01 17:57:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jun Aruga 2018-10-10 12:01:37 UTC
Description of problem:

This is a proposal.
Right now python37, python35, python34, python33 packages are built with enabled "flatpackage" macro.

I would like that the test directory is separated as a python37-test package even when "flatpackage" enabled.
Because the test directory is maybe not used, right? And it occupies 48MB/93MB = more than 50% of the total size.

```
$ rpm -qf /usr/lib64/python3.7/test/
python37-3.7.0-1.fc28.x86_64

$ du -sh /usr/lib64/python3.7
93M	/usr/lib64/python3.7

$ du -sh /usr/lib64/python3.7/test/
48M	/usr/lib64/python3.7/test/
```

I am fine that the modification is just updated to rawhide.

Version-Release number of selected component (if applicable):
python37-3.7.0-1.fc28.x86_64
python35-3.5.6-1.fc28.x86_64
python34-3.4.9-2.fc28.x86_64
python33-3.3.7-5.fc28.x86_64


Additional info:

Comment 1 Miro Hrončok 2018-10-10 12:48:54 UTC
I personally don't like this. The decision was made that those packages would be plan flat. Can you please bring this up in python-devel mailing list for more audience?

Comment 2 Jun Aruga 2018-10-10 13:24:44 UTC
Alright. I sent email to the mailing list now.

Comment 3 Petr Viktorin (pviktori) 2018-10-11 11:40:02 UTC
I'm torn.
If we split out -tests, why not the other subpackages? tkinter brings in all of X11, or whatever the graphical stack is nowadays -- and that's also huge, IIRC.
(But it's shared with other packages.)

While 48MB is not that much, a major use case involves having 6 of these interpreters installed. It does add up.

Comment 4 Miro Hrončok 2018-10-11 11:43:06 UTC
The other thing is that once we start optimizing this for space, people will deploy it in containers etc.

I don't think that 300 MB of unused tests is a deal breaker on a developer machine.

Comment 5 Petr Viktorin (pviktori) 2018-10-11 11:49:01 UTC
> The other thing is that once we start optimizing this for space, people will deploy it in containers etc.

Testing containers?

Comment 6 Jun Aruga 2018-10-12 18:43:55 UTC
> I don't think that 300 MB of unused tests is a deal breaker on a developer machine.

My machine has only 50 GB in the root partition including /usr directory.
I regularly have to clean files.

```
$ df -h
Filesystem                              Size  Used Avail Use% Mounted on
...
/dev/mapper/fedora_unused--4--164-root   50G   42G  5.2G  89% /
...
/dev/mapper/fedora_unused--4--164-home  178G   66G  104G  39% /home
...
```

Comment 7 Charalampos Stratakis 2018-11-01 16:37:58 UTC
I am posting the same answer I gave at the mailing list:

"Hello Jun, That is actually a valid concern and testing with multiple python interpreters is not the most disk-space friendly use case.

However those packages were intended to be flat, the whole interpreter in one binary rpm. In my opinion it's the only pragmatic choice when you take into account the maintenance burden of so many interpreters.

Also if we split the tests to a subpackage I can imagine having requirements for splitting them up more in the future as well. Thus I would say that I wouldn't like to split them up and just keep them as it is.

I'd be open of course to other possible solutions/arguments."

Thus in this case I would call this a feature or something that I wouldn't fix. It sort of defeats the purpose of those packages and it increases the maintenance burden (that we already carry a lot).

Also as a side note, I had a similar issue with my root partition and I realized that mock was actually caching gigabytes of rpms in my root partition which made me symlink its folder to home. Maybe that could save some more space in the long run.

Overall I'm inclined to close this as WONTFIX.

Comment 8 Jun Aruga 2018-11-01 16:57:14 UTC
Hello, Charalampos.
Your opinion makes sense. I am fine to close this ticket with WONTFIX.

> Also as a side note, I had a similar issue with my root partition and I realized that mock was actually caching gigabytes of rpms in my root partition which made me symlink its folder to home.

Yeah, mock cache is big size.
And /var/cache/PackageKit too [1]. I deleted the cache files.
Now I am moving the files on /usr/local and /opt to /home, making the symlink.
Thanks for the suggestion!

[1] PackageKit accumulate over 18GBytes of RPM packages in /var/cache/PackageKit/metadata and fill my root filesystem with unused RPM files
https://bugzilla.redhat.com/show_bug.cgi?id=1306992

Comment 9 Charalampos Stratakis 2018-11-01 17:57:54 UTC
per comment 8 , closing this as WONTFIX.