Red Hat Bugzilla – Bug 644183
Code::Blocks uses bundled copies of Scintilla and wxScintilla
Last modified: 2015-02-18 08:30:12 EST
Description of problem:
Code::Blocks bundles a copy of wxScintilla from http://wxcode.sourceforge.net/components/wxscintilla/ in src/sdk/wxscintilla which should be packaged separately. wxScintilla itself bundles a copy of the Scintilla core, which itself can be found under src/sdk/wxscintilla/src/scintilla in Code::Blocks.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Look for bundled libraries.
No bundled libraries.
src/sdk/mozilla_chardet is also bundled copypasta, but that one doesn't seem to be a proper library at all. :-(
The above URL contains a dead branch and AFAIK it wasn't clear for a long time where the development happens/should happen and users of wxScintilla did patch their copies. I'll see how feasible is to switch to wxScintilla from wxWidgets what should be the primary source these days.
C::B uses a forked copy of scintilla with changes that are specific to C::B, so even a new development (that didn't happen yet) in wxScintilla won't help here. See
http://forums.codeblocks.org/index.php/topic,13538.0/topicseen.html for more details.
Sorry, you can't close this that easily :-(
Here's the choices -- I'd like to see some discussion about whether C::B upstream would be willing to become the canonical source for wxscintilla since it is dead upstream. As they themselves note, wxscintilla being dead upstream means that there's a proliferation of bundled copies in many projects. This leads them all to need to duplicate each others work fixing bugs, adding features, responding to security issues, etc. In the long run, taking over development and getting all the forks to merge will be a time benefit to them.
The scintilla problem is different. Upstream C::B has apparently decided that their changes wouldn't be acceptable to upstream scintilla and that their changes aren't useful to others either. Have they sent their changes for upstream consideration to determine that or are they just guessing? Especially when asking whether other projects might want the more featureful version of scintilla (and thus, whether they should have a forked version available for everyone to use and contribute to just like the wxscintilla case) I'm wondering how they've determined that they should be the only consumers.
If they feel they must fork the code then you must ask FESCo to grant an exception. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions
And if you are granted an exception, you need to add the virtual Requires: as outlined here:
The situation is following - C::B bundles wxScintilla, wxScintilla bundles scintilla. The scintilla in C::B is now modified to fit C::B (exclusively) needs and some of the general changes were rejected by upstream (see reply #11 in the thread). So becoming upstream for wxScintilla doesn't make any sense for them.
So preparing the facts for fesco, the exclusively argument should be prove/document. Why are the changes only useful to C::B?
With the general changes rejected by upstream, you probably also want to find out why those changes weren't taken because that could have implications on the maintenance burden we're potentially taking on in helping to maintain a codebase that has those changes.
They say that they've submitted their changes to scintilla upstream, have they also submitted their changes to wxwidgets to see if we can get them into the copy of libraries there? Right now we're bundling scintilla in both places.
Related to the last question -- Our wxGTK package is bundling scintilla. Do you want to unbundle that or try to merge the bundled scintilla from C::B with that and try to get an exception for just one bundled scintilla there?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.