#126 bundling exception for scintilla
Closed: Fixed None Opened 7 years ago by mmaslano.

There is needed bundling exception for perl-Wx-Scintilla, which is needed for update of Padre (Perl IDE). I spoke with upstream about whole issue and they can't unbudle. It looks okay to me, but I'd like to have clarification from FPC.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=757657


I'm attaching my conversation with Ahmad.

Hi Marcela,

Thanks for following up on this one and I am really sorry but $life and $work can really affect hacking time.
Please see my answers to your questions.

I guess Wx::Scintilla couldn't worked without bundle, but from packagers

point of view it's simply wrong to bundle and modify sources. I know
it's common for Java and Desktop, because bundled applications work well
on Mac and Windows, but it's a nightmare for security teams of Linux
distributions.

I know it is wrong but let us be pragmatic about it. It is a security nightmare for all administrators. True. But Padre is not a server-side tool.

Currently, I'm stuck with review of mentioned package [1], and I need
few answers before I'll ask for re-review and packaging exception.

Wx-Scintilla-0.34/wx-scintilla/src/scintilla/src
 * it's a copy of files from scintilla/{lexers,lexlib,src} according to
README.txt, but there are more files. Could you clarify in next release
and also add link to upstream project?

Wx-Scintilla-0.34/wx-scintilla/src/scintilla/include
 * contains scintilla/include  but without *.py file. Could be also
mentioned in README.txt.

Updated README.txt. Please check it out.

Wx-Scintilla-0.34/wx-scintilla/src/scintilla/License.txt
 * it's strange MIT license, but ok.

It is the same license as scintilla.

Wx-Scintilla-0.34/wx-scintilla/include/*
 * They are under wxWindows/wxWidgets license, which means they can be
copied, but can not be modified. I need to know what's the upstream of
those two files.

Cannot be modified? "...This library is free software; you can redistribute it and/or modify it...". We modified it heavily to fix bugs etc... It was outdated compared to current Scintilla.

Answers would really help me with the update of Padre.

I hope I helped you. Please let me know if you need anything else. I will push an experimental Scintilla package that is based on Scintilla 3.0.2.

Thank you,
Marcela

No thank you :)

Question: do we need to put README.txt License.txt in all folders or simply summarize them in a single README in the top folder? Please note that those are really artifacts from the wxWidgets project that we fixed and updated for wxWidgets 2.8.x and latest Scintilla.

Have fun,
Ahmad M. Zawawi

[1] https://bugzilla.redhat.com/show_bug.cgi?id=757657

It seems like the Padre upstream is going to put out a release that uses the modern Scintilla (3.0.2), and thus, it should be possible to have Padre use the modern system copy of Scintilla. If this is the case, there should not be a need for a bundling exception here.

If this is not the case, we would need to have some detailed explanation of why the system copy of Scintilla can not be used with Padre.

Ok, I use for new official release of Padre using new Scintilla. But in the old version they changed lot of things, so it was probably the only viable solution.

The new release of Padre and Wx::Scintilla is out. The Wx::Scintilla is based on scintilla-3.0.2, but they are adding a lot of their own files. I'm adding link on diff between the upstream scintilla source and the scintilla from Wx::Scintilla modification.

http://mmaslano.fedorapeople.org/bugy/scintilla.diff

I guess they are modifying it too much for using the original. What exactly should I ask? The upstream didn't get why we are so paranoid about bundling, because the main author is Java programmer ;-)

So, they do not appear to be making any changes to the scintilla code base, just adding new files to it. Why can't the code just drop all the scintilla-3.0.2 files, leave these additional files, and link to the shared scintilla lib?

Of course, as I type this, I realize that there is not currently a "plain" scintilla packaged in Fedora, just qscintilla...

I have another reply from upstream, because I almost gave up packaging of the component:

We had the same discussion with Debian. Wx::Scintilla is scintilla compiled for your wxWidgets platform. wxWidgets was moving and still is moving very slow. You get the latest scintilla ported to your old wxWidgets platform. It does not change anything to scintilla source tree (other than including a simple Perl 6 lexer). It only implements its wxWidgets platform that Scintilla can use.

As you can see even Debian accepted the package: http://packages.debian.org/wheezy/libwx-scintilla-perl

Scintilla is somewhat like WebKit. There has been many ports of Scintilla in Fedora, like Geany, qscintilla, Code::Blocks, etc., just like webkitgtk, qtwebkit for WebKit. It won't be possible for a shared WebKit component that can be used in all kinds of widget libraries. And so as for Scintilla.

So we may need a bundling exception for Scintilla in general, not only for perl-Wx-Scintilla.

Thanks for recommendation. I almost gave up :) updates of Padre.

I believe scintilla is usually used in applications as a bundle or with changes. I found in Fedora only qscintilla and PyQt-qscintilla.

I guess package perl-Wx-Scintilla as is will be the easiest approach. Otherwise I have to change directories and create diff for every update of package.

Please update this ticket regarding its continued relevance, providing any
information requested. If this is not done within the next two weeks, this
ticket may be closed due to inactivity. Thank you!

I do not have time to work on it. If someone want to update Padre in Fedora, then he should solve this problem. I'm closing my request.

We need this exception for:

(1) upgrading perl-Padre

(2) legalizing qscintilla.

It's shame FPC was not able to decide in more a year.

Can you provide the requested information?

Replying to [comment:13 james]:

Can you provide the requested information?
What requested information? I cannot see any question except the original notting's one if wx::scintilla can unbundle scintilla.

But this is not important anymore because bundling scintilla is a problem of much more already existing packages as pointed in [comment:7 comment #7].

Either FPC has to grant general exception for the scintilla, or it has to remove these packages from Fedora. Neither action violates Fedora guidelines.

This FPC ticket should CC owners of codeblocks, geany, qscintilla, etc. But I'm not allowed to add people to the ticket CC list.

To repeat the main problem. Wx-Scintilla is bundling and modifying qscintilla. Other packages in distribution are doing the same, so it would be nice to have an exception also for this package.

We talked about this at today's meeting (​​​​​​​​​http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-12/fpc.2015-02-12-17.05.txt):

(Edited to improve formatting)

Tried to do a little digging. Here's what appears to be bundling scintilla-related things:

geany (bundles scintilla 3.3.6 from Oct 2013)[[BR]]
codelblocks (bundles wxScintilla 1.7.1)[[BR]]
qscintilla (bundles some undetermined version of scintilla)[[BR]]
wxPython (bundles scintilla 3.2.1)[[BR]]
wxGTK (bundles scintilla 1.70)[[BR]]
wxGTK3 (bundles scintilla 3.2.1)[[BR]]
ogre (bundles wxScintilla 1.69.2)[[BR]]
monkeystudio (bundles qscintilla, some pre-2.6.3 snapshot)[[BR]]

I think scite might bundle scintilla in some way.

Current version of scintilla appears to be 3.5.3, released not even a month ago.

wsScintilla appears to be unmaintained. Upstream says the latest version is 1.66.0 but ogre appears to have something newer. I'm not sure what codeblocks has, but it could be really ancient.

Current version of qscintilla is 2.8.4.

Now, really, this is hilarious. We have one project bundling something which bundles something else. Scintilla is active upstream and everything else is way, way out of date. I tried to do some diffing versus historical releases of scintilla and pretty much everything modifies it in some way. This is a classic example of why bundling is so bad.

Not sure where to go from here. I've probably missed a few things but codesearch.debian.net was useful.

With my qscintilla-2.8.4 maintainer hat on, it's docs claim:
This version of QScintilla is based on Scintilla v3.3.6.

It seems that 3.3.6 and 3.2.1 are popular for some reason. Neither are the last releases under their series (that would be 3.3.9 and 3.2.5) so... I don't know.

We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-12/fpc.2015-03-12-17.00.txt):

  • 126 bundling exception for scintilla (geppetto, 17:38:16)

  • LINK: https://fedorahosted.org/fpc/ticket/126 (geppetto, 17:38:23)
  • ACTION: Given the scope of the bundling here, we need input from the
    other package maintainers. At the very least they should have
    bundled() provides, better would be to help unbundle this giant
    mess. (geppetto, 17:47:49)

I'm adding a boatload of CCs to this ticket. I apologize to everyone involved for the spam but it would be nice to move this forward somewhat. I'm just contacting everyone this way instead of filing a bunch of tickets in bugzilla, but I'll get down to that eventually if we can't resolve things here.

As a summary, we're trying to figure out what we can do about all of the bundled scintilla versions that are floating around. A while back I identified the following packages:

{{{
geany (bundles scintilla 3.3.6 from Oct 2013)
codelblocks (bundles wxScintilla 1.7.1)
qscintilla (bundles scintilla 3.3.6)
wxPython (bundles scintilla 3.2.1)
wxGTK (bundles scintilla 1.70)
wxGTK3 (bundles scintilla 3.2.1)
ogre (bundles wxScintilla 1.69.2)
monkeystudio (bundles qscintilla, some pre-2.6.3 snapshot)
}}}

Some packages bundle other packages which bundle scintilla. This situation is kind of hilarious and we'd like to clean it up to the extent that's possible.

If you maintain one of the packages above, please double check my list above, see what your package is actually bundling, and then try to see if it's possible to get rid of the bundled code (checking with upstream if possible). If not, please try to let us know why. If the bundled code has been modified, please tell us how it has been modified; provide links to diffs if possible, or at least describe the extent of any modifications.

Also, unless I'm wrong and you really aren't bundling scintilla, please add Provides: bundled(scintilla) = version to your packages. (Or for those that are bundling something which bundles scintilla, please just indicate what you're bundling using that mechanism.) That way we can at least track this mess.

Fwiw, qscintilla-2.9 (recently landed in rawhide) includes scintilla-3.5.4, and I just added the Provides: as advised.

Turns out monkeystudio includes a copy of qscintilla but builds using the system version, so it's OK.

I have added the necessary Provides: to the other packages. That doesn't resolve this, but at least they can be tracked. I'll remove the monkeystudio maintainer from this ticket.

Turns out that wxPython is OK as well; the source bundles wxGTK but doesn't use it. So that's two down.

Adding the scite maintainer as a CC.

Looks like I missed something else bundling scintilla. Unfortunately it was missed on a relatively recent review, even though the bundling is really obvious. Looks like it's bundling version 3.5.5 of scintilla; at least it's up to date (which isn't surprising since scite and scintilla are developed together).

opuk, could you add Provides: bundled(scintilla) = 3.5.5 to the package? That will at least let us track the fact that it's being bundled.

To actually make any progress on fixing this, of course, someone's actually going to have to provide an actual scintilla package. scite itself is the closest to upstream, and it links scintilla statically. I'm not even sure scintilla has the capacity to function as a shared library.

bundled(scintilla) is fixed in rawhide now, I will update branches shortly.

As FPC is now no longer in the business of approving or disapproving bundling requests, there's nothing left to do here.

Metadata Update from @rdieter:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata