2:06 p.m.
notwithstanding my post on the f-devel ML, ...
Probaby there should some work on communicating the need to
turn down EPEL 6 at 2020 11 30, and with it those python
2 modules by that time
Smooge, if from the logs you can comb mirroring apart from
installlation pulls, having a ranked list of python(2)
candidates, to point
The python 2 in EPEL 7 (I see a mess of them), despite under
40 or so python 2's in base / update RHEL, it may make sense
to see of one of the automated conversion rubric will work on
say 80 pct of the packages there. Perhaps simply filing bugs
asking the question for each, so we can garner some stats
-- Russ herrold
5:07 p.m.
On 07/16/2018 12:06 PM, R P Herrold wrote:
notwithstanding my post on the f-devel ML, ...
Probaby there should some work on communicating the need to
turn down EPEL 6 at 2020 11 30, and with it those python
2 modules by that time
Sure, smooge usually beats the drum on that a year in advance then
multiple times leading up to retirement (at least that was the case for
rhel5/epel5).
Smooge, if from the logs you can comb mirroring apart from
installlation pulls, having a ranked list of python(2)
candidates, to point
The python 2 in EPEL 7 (I see a mess of them), despite under
40 or so python 2's in base / update RHEL, it may make sense
to see of one of the automated conversion rubric will work on
say 80 pct of the packages there. Perhaps simply filing bugs
asking the question for each, so we can garner some stats
I'm confused here. I doubt very much RHEL is going to drop python2 from
rhel7. Thus epe7 packages should be able to go on as they have...
kevin
6:29 p.m.
On Tue, 17 Jul 2018, Kevin Fenzi wrote:
I'm confused here. I doubt very much RHEL is going to drop
python2 from rhel7. Thus epel7 packages should be able to go
on as they have...
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 lings to the mainfests
tomorrow. A 'sort | uniq' let me down as to getting an
accurate count released today
Yes, for now there is not an issue, but I was just looking
ahead to 2024 06 30 (the current published RHEL 7 initial EOL,
pre Extended), and figuring out the enterprise user conversion
loads, assuming RHEL 8 (tm) drops with a simple python(3), and
no backward support python(2)
-- Russ herrold
1:24 p.m.
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
4:43 a.m.
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.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.
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/...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:12 a.m.
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
2106
days inactive
2109
days old
epel-devel@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Kevin Fenzi -
Miro Hrončok -
R P Herrold