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. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx