On Tue, 17 Jul 2018, R P Herrold wrote:
I've poked at getting accurate counts and manifests of unique python(2) package SRPMs off my mirror today -- I'll supplement this email with the script and links to the mainfests tomorrow. A 'sort | uniq' let me down as to getting an accurate count released today
tomorrow arrived on me, but here are the promised report and links to the results and the generator script
[/share/MD0_DATA/Mirror/lftp] # time ./stats.sh # packages starting with target: python # but NOT python3 # collated from a mirror: 20180718
264 /tmp/redhat_rhel_SRPMSonly_6Server.txt 475 /tmp/redhat_rhel_SRPMSonly_7Server.txt 644 /tmp/redhat_epel_6.txt 825 /tmp/redhat_epel_7.txt 2776 /tmp/redhat_fedora_fedora-28.txt 2132 /tmp/redhat_rawhide2017.txt
real 64m28.714s user 1m11.330s sys 3m6.450s
The first column is the number of unique SRPMs for a given archive, seen. Inside the files (the link of which is my second column and the basename of which is accessible per the links below) are detail counts of the number for each distinct SRPMs within a given package name, as seen on a local private mirror I use and maintain
Copies of the detail, and of the script producing the reports are at:
http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt http://gallery.herrold.com/stuff/redhat_epel_6.txt http://gallery.herrold.com/stuff/redhat_epel_7.txt http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt http://gallery.herrold.com/stuff/redhat_rawhide2017.txt
http://gallery.herrold.com/stuff/stats.sh
The _purpose_ of getting the count of 'number of updated packages' for each given package is to permit seeing 'hot spots', and the 'no issues' 'build once and forget' packages particularly in RHEL and EPEL. Because of the way that current Fedora and RawHide are built, there is churn on rebuilds, even with non-material internal changes. THe
The ** POINT ** of producing such a report is to 'put numbers' on the scope of the work rather than loose armwaving assertions such as:
Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help.
I did not try to structure and run a report to try to enumerate and count by dependencies. Looking at the problem with such a statistic, as to 'upstream' 'keystone' packages will, I suspect, show that many of the dependencies almost certainly 'cluster around a few 'branch' packages
-- Russ herrold
On 18.7.2018 20:24, R P Herrold wrote:
On Tue, 17 Jul 2018, R P Herrold wrote:
I've poked at getting accurate counts and manifests of unique python(2) package SRPMs off my mirror today -- I'll supplement this email with the script and links to the mainfests tomorrow. A 'sort | uniq' let me down as to getting an accurate count released today
tomorrow arrived on me, but here are the promised report and links to the results and the generator script
[/share/MD0_DATA/Mirror/lftp] # time ./stats.sh # packages starting with target: python # but NOT python3 # collated from a mirror: 20180718
264 /tmp/redhat_rhel_SRPMSonly_6Server.txt 475 /tmp/redhat_rhel_SRPMSonly_7Server.txt 644 /tmp/redhat_epel_6.txt 825 /tmp/redhat_epel_7.txt 2776 /tmp/redhat_fedora_fedora-28.txt 2132 /tmp/redhat_rawhide2017.txtreal 64m28.714s user 1m11.330s sys 3m6.450s
The first column is the number of unique SRPMs for a given archive, seen. Inside the files (the link of which is my second column and the basename of which is accessible per the links below) are detail counts of the number for each distinct SRPMs within a given package name, as seen on a local private mirror I use and maintain
Copies of the detail, and of the script producing the reports are at:
http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt http://gallery.herrold.com/stuff/redhat_epel_6.txt http://gallery.herrold.com/stuff/redhat_epel_7.txt http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt http://gallery.herrold.com/stuff/redhat_rawhide2017.txt
http://gallery.herrold.com/stuff/stats.sh
The _purpose_ of getting the count of 'number of updated packages' for each given package is to permit seeing 'hot spots', and the 'no issues' 'build once and forget' packages particularly in RHEL and EPEL. Because of the way that current Fedora and RawHide are built, there is churn on rebuilds, even with non-material internal changes. THe
The ** POINT ** of producing such a report is to 'put numbers' on the scope of the work rather than loose armwaving assertions such as:
Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help.
Those are real Fedora numbers [0]. No armwaving involved.
1311 python2 only packages 1734 python2+python3 packages + 88 with packaging problem where I'm not sure
That is something between 3045 and 3133. That can be rounded to 3k.
No idea why we moved the discussion to another list as well, but stop accusing us from armwaving. We have data (for Fedora, because that where we started the discussion). As for RHEL/EPEL: current ones can remain as they are. Future ones see [1].
Python 2 will be replaced with Python 3 in the next Red Hat Enterprise Linux (RHEL) major release.
[0] http://fedora.portingdb.xyz/ [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
On Thu, 19 Jul 2018, Miro Hrončok wrote:
The ** POINT ** of producing such a report is to 'put numbers' on the scope of the work rather than loose armwaving assertions such as:
Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help.
Those are real Fedora numbers [0]. No armwaving involved.
1311 python2 only packages 1734 python2+python3 packages
- 88 with packaging problem where I'm not sure
That is something between 3045 and 3133. That can be rounded to 3k.
No idea why we moved the discussion to another list as well, but stop accusing us from armwaving. We have data (for Fedora, because that where we started the discussion). As for RHEL/EPEL: current ones can remain as they are. Future ones see [1].
"accusing" ? I think it is pretty clear that more than a little projection is going on here. I offered a description of methodology, hard numbers on six archives, and the generation script to nail down numbers. Before your most recent email, .... nope
The _reason_ that it was off an EPEL thread (EPEL of course being PART OF FEDORAPROJECT, last time I looked) is that is the harder one to solve, and also there was a thread going as to planning a meeting, of which that hard data was a part
If I go to a car dealer and seek to buy a car and ask a price, and am told by the salesperson:
"more than 3000" dollars
they have not yet not told me a price they will sell the car at
-- Russ herrold
Good numbers to provide, thanks. I've one thought for you.
On Wed, Jul 18, 2018 at 2:24 PM, R P Herrold herrold@owlriver.com wrote:
I did not try to structure and run a report to try to enumerate and count by dependencies. Looking at the problem with such a statistic, as to 'upstream' 'keystone' packages will, I suspect, show that many of the dependencies almost certainly 'cluster around a few 'branch' packages
-- Russ herrold
Numbers of dependencies are useful to report. I'd also expect "hot spots" around packages that are simply incompatible with python 3, or incompatible with python 2, due to the syntax differences between the languages. That's not going to be solvable by merely updating .spec files.
Hmm. Has anyone take a look at the "bdist_rpms" python tools, used by Python developers to build RPMS from their raw python code, to bring it up to Fedora standards? Or py2pack? Getting those updated could help.authors of new smf p;f python tools. follow new standards.
-
Miro Hrončok -
Nico Kadel-Garcia -
R P Herrold