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
>>>> Do you think it'd be possible to script the python-foo to
>>>> 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
>>>> significantly cut down on the number of misnamed packages and let
>>>> packagers spend their times on the ones where the automatic way is not
>>> I was going to ask whether it might be possible to tweak
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?"
>>> 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
>>> 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 .
>> See logs  and the diff  (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 . 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
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.