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(a)in.waw.pl>
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.
Zbyszek