Upstream of [http://www.eclipse.org/sisu/ Eclipse Sisu] is using bundled [http://asm.ow2.org/ Objectweb ASM library], version 4. Parts of source code of ASM are included in source of Sisu with minor modifications, primarly changing namespace and removing parts unused by Sisu.
Previously Sisu was using ASM as external library, but this was recently changed. ASM [http://bugs.eclipse.org/bugs/show_bug.cgi?id=406612 was embedded to overcome some technical difficulties], see below. Fedora sisu package used to use objectweb-asm as a third party dependency, but with update to recent upstream version it started using embedded (bundled) copy.
Currently there are two versions of ASM library included in Fedora, 3 and 4. These two versions are not compatible and porting from version 3 to 4 is not straightforward. Currently version 3 is directly used by 64 packages, so migration to version 4 is practically impossible, at least not any time soon. Version 4 is used by 13 packages.
Sisu is a dependency of Maven -- a popular Java build system that is built using plugin architecture. ASM is a popular library and version 3 is definitely the most popular. If Sisu was using ASM 4 as external library then some plugins or extensions created for upstream Maven which use ASM 3 wouldn't work with Fedora Maven as two incompatible versions of the same library would be mixed together in the same namespace. Upstream realizes that and that't the reason for embedding ASM 4. For Fedora Maven it is extremly important to keep compatibility with third-party plugins which target upstream Maven.
Hereby I request for Eclipse Sisu package(s) to be allowed to bundle ASM library with a modified namespace under following conditions:
1. Bundled source code of ASM will be removed from Sisu sources before build,
1. ASM binaries will be taken from Fedora objectweb-asm4 package and will be transformed at build time of Sisu package(s) to change namespace to Sisu-specific (in a simillar way as byteman package does, #226),
1. such transformed ASM code will be used to build Sisu package(s) and will be installed with Sisu binary RPMs,
1. Provides: bundled(objectweb-asm4) will be added to Sisu package(s) that contain bundled code of ASM.
One package already has an exception to bundle ASM library, see #226. Note that this request is for a different version of ASM library.
Discussed at today's meeting. FPC is much more inclined to grant a temporary exception than a permanent one as this is a case where the plugins need to catch up with the core. Can you give us a time frame that we could grant a temporary exception for? If the time frame is large, please do let us know so that we can decide whether we're okay with this on a different basis.
This should have been moved to needinfo 16 months ago, but that doesn't really change the fact that we've been writing for an answer to comment 2 for 16 months. If this is still relevant, please provide the requested information.
This request is still relevant. I'm not satisfied with temporary bundling exception because upstream is not going to unbundle ASM (they have valid reasons for bundling) and I cannot unbundle ASM without breaking compatibility with upstream.
Thanks, I'll move this to the meeting agenda. If you have any additional information to add which you think might help us make a decision, please feel free to add it at any time.
Was there any attempt to work with ASM upstream so that ASM3 and ASM4 could co-exist?
ASM API was already redesigned for backwards compatibility - ASM4 and any further version are compatible. But changing APIs of already released versions is not possible, so there is nothing that I can do about that.
One question I had at the last meeting was whether it's possible to somehow automatically re-namespace ASM and provide the differently-namespaced version as a subpackage of the regular ADM package upon which sisu could depend. That would seem to eliminate the entire issue.
Yes, that would be possible.
FPC did not have time to discuss this at today's meeting but it remains on the agenda for next week.
However, if what's in comment 8 possible and you and the ASM maintainer (assuming that's not also you) are amenable, it seems (to me) to be simplest to just do that and not involve FPC at all. It also seems like this would eliminate some work as updating ASM would automatically give you an update to the mangled version as well.
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):
Metadata Update from @mizdebsk:
- Issue assigned to tibbs
to comment on this ticket.