#436 Bundled code advise for shiboken
Closed: Fixed None Opened 5 years ago by jreznik.

Hi,
shiboken can now be built only using bundled code for apiextractor and generatorrunner due to changes in python-sphinx.

Both apiextractor and generatorrunner are dead upstream as standalone projects (not releases anymore) and fixes are only shared as part of bundled code in shiboken. It does not make sense to fork and maintain standalone version just for Fedora as other distributions now use bundled code and it's not used by any other project than shiboken. Also upstream considers bundled code as integral part of shiboken.

{{{
repoquery --whatrequires apiextractor
apiextractor-devel-0:0.10.10-5.fc20.i686
apiextractor-devel-0:0.10.10-5.fc20.x86_64
generatorrunner-0:0.6.16-4.fc20.i686
generatorrunner-0:0.6.16-4.fc20.x86_64
shiboken-0:1.1.0-3.fc19.x86_64

repoquery --whatrequires generatorrunner
generatorrunner-devel-0:0.6.16-4.fc20.i686
generatorrunner-devel-0:0.6.16-4.fc20.x86_64
shiboken-0:1.1.0-3.fc19.x86_64

}}}

For independent observer, code could look like bundled code but based on stated above, it's actually integral part of code. Is still exception required or explanation in SPEC would be enough? If exception is needed, I'd like to ask for it.

Would be nice to sort out this issue in advance of F21 branching.


You must have an exception. You probably want to answer the standard questions to make this go faster. I'm also wondering why python-sphinx is a blocker here... it's generally only used for building documentation. (OTOH, shiboken helps with creating language bindings so there could be some correlation here I just would like to know what it is.)

Replying to [comment:1 toshio]:

You must have an exception. You probably want to answer the standard questions to make this go faster. I'm also wondering why python-sphinx is a blocker here... it's generally only used for building documentation.

Shiboken documentation uses sphinx.ext.refcounting extension that has been dropped in Sphinx 1.2. See https://bugreports.qt-project.org/browse/PYSIDE-221

Most of the standard questions were answered above, formal way is here:

  • Q: Has the library behaviour been modified? A: Yes, to fix build issues.
  • Q: Why haven't the changes been pushed to the upstream library? A: Bundled code is now upstream
  • Q: Could we make the forked version the canonical version within Fedora? A: We could, but shiboken is the only consumer
  • Q: Are the changes useful to consumers other than the bundling application? A: No, shiboken is the only consumer of these libraries and upstream continues development only in the bunded code, not the standalone projects
  • Q: Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release? A: Bundled libraries are now where upstream development happens
  • Q: What is the attitude of upstream towards bundling? A: As there were no other consumers of standalone libraries, upstream decided to work only on bundled code and actually merge it to the codebase
  • Q: Overview of the security ramifications of bundling A: Original upstream is unmaintained, as the only development happens on in-tree bundled code, it actually leads to higher security, it would be hard to sync all changes to our own forked versions
  • Q: Does the maintainer of the Fedora package of the library being bundled have any comments about this? A: The same maintainer - me, and as I proposed to go only with bundled code, no additional comments.
  • Q: Is there a plan for unbundling the library at a later time? A: No, upstream development happens in-tree of shiboken
  • Q: Please include any relevant documentation

pyside IRC channel

[15:13] <jreznik> and another question - is apiextractor and generatorrunner dead and bundled code is used in shiboken (so fixed for sphinx update?)
[15:15] <odyx> yes

GIT repos as an evidence https://qt.gitorious.org/pyside/ - see fixes going only to shiboken + http://qt-project.org/wiki/PySide

So I ask formally to grant an exception to bundle apiextractor and generatorrunner in shiboken code as it's now the canonical upstream in-tree code.

From information in your comment and some further clarification from rdieter it seems like the apiextractor/generatorrunner devs have merged their code into the shiboken tree rather the devs of those projects disappeared and the shiboken devs decided to bundle the code into their tree. That would be justification to approve this for us. Other factors that we discussed were that apiextractor and generatorrunner seem to just be used at build time and that no one else uses it.

So far voting in the meeting we only had four people to vote. Voting so far:

  • +1: geppetto, abadger1999, RemiFedora, SmootherFrOgZ
  • 0: 0
  • -1: 0
  • Need one more +1 from tibbs, spot, Rathan, limburgher, or racor

Login to comment on this ticket.

Metadata