On 29.7.2017 01:27, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jul 28, 2017 at 11:11:05PM +0200, Miro Hrončok wrote:
On 28.7.2017 22:44, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jul 28, 2017 at 05:51:39PM +1000, Nick Coghlan wrote:
On 28 July 2017 at 03:15, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
Do you think it'd be possible to script the python-foo to python2-foo
renaming? If yes, then maybe it'd make sense to just get some pps to
do it in rawhide now and get the "easy" part done with? That should
significantly cut down on the number of misnamed packages and let
packagers spend their times on the ones where the automatic way is not
obvious.
I was going to ask whether it might be possible to tweak
http://fedora.portingdb.xyz/ to also report on compliance with the
naming policy, but then I went and saw that it *does* already report
on that: http://fedora.portingdb.xyz/namingpolicy/
While it also turns out the wiki page already links to that page, it
may be good to call it out a second time in a "How can I help?"
section.
Checking an initial sampling of spec files (python-d2to1,
python-BeautfulSoup, python-amqplib) suggests to me that a script
implementing the following rules might offer a reasonably start point,
at least for Python-2-only modules that are remaining Python-2-only:
- immediately before the first BuildRequires or Requires entry, add a
%package section header for "-n python2-<name>" (where "<name>" is the
lowercased package source name with any "python-" prefix stripped)
- add a %python_provides entry after the new package header in
accordance with the current guidelines
- if the original package provided a non-lowercase "python-*"
provides, remote it and add a second %python_provides with the
original capitalisation
- if the source package lacks the "python-" prefix, add a virtual
provides for the unqualified package name
- add a "-n python2-<name>" qualifier to any currently unqualified
description and files sections
A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for the default subpackage).
I hacked up a script, it's on pagure now [1].
See logs [2] and the diff [3] (unfortunately no highlighting on paste.fp.o.).
This does 561 python-* packages, out of 645.
Wow, nice job!
I took the list from portingdb, but it seems partially outdated, 32
packages already have %python_provide python2-*.
One more by hand (patch in repo).
That leaves 51 packages to convert by hand (mostly because of conditionals
which are too complicated to do automatically).
So, please take a look at the diff [3]. If you want to adapt the
script, ping me, and I'll add you to the repo.
After I started working on this, I limited it to python-* packages,
because those are easiest. There's 237 other packages on the portingdb
list. I *would* be possible to make the script work for those packages
which are pure python and just have an old name. I don't think it makes
sense to do other packages which just have a python subpackage this way.
This would be a good start, I think. Before being pushed anywhere,
it'd need to be checked carefully of course and extended to some of
the remaining packages. I'd apply this as one step, and rebuild everything.
After that, it'd be easier to convert *dependencies*, because all or most
python2- names should be available. Some time after current mass rebuild
is done?
That sounds like something that would need to be approved by FESCo,
isn't it?
Yes. That's what I said before too. I would like to see buy-in from
you and Nick and other python gurus before submitting it anywhere else
though.
I just had a discussion with Tomáš Orsava and Petr Viktorin on
#fedora-python. Rather than asking FESCo now to allow mass
fully-automated spec changing, we'll open bugs as planned, but we'll
attach patches generated by your script to them. We'll see if people
tend to accept them and gather any feedback. If those patched are
generally accepted, we can then use this to support our request t FESCo.
If not, we might want to change the script or abandon the idea.
Since Fedora 27 is already at the testable deadline, we would do this in
rawhide after F27 branching at a very soonest, so I guess we can spare
some time and proceed slowly.
We can revisit this discussion (whether to ask FESCo for permission to
automatically fix the specfiles) before the Proposal submission deadline
for Fedora 28 (that's January 2018). Until then, we should already have
some feedback from the open bugzillas.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
