Bug 847130 - noarch packages may depend on arch-independent bytecode in %{_libdir}/eclipse
noarch packages may depend on arch-independent bytecode in %{_libdir}/eclipse
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Alexander Kurtakov
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-08-09 15:41 EDT by Roland Grunberg
Modified: 2012-12-27 09:15 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-12-27 09:15:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Roland Grunberg 2012-08-09 15:41:11 EDT
There are noarch packages that may depend on bytecore in swt.jar in %{_libdir}/eclipse , but in rawhide (and now in f18), noach packages can't resolve %{_libdir}. As a workaround we call rpm --eval on the %{__isa_bits} macro, and this seems to resolve within a build (whereas the macro itself called directly wouldn't be resolved). This isn't ideal, but seems to work.

Given that references to %{_libdir} from a noarch package are no longer supported, is there a plan to split the native and arch-independent bytecode of swt.jar into separate packages ? What happens to any noarch packages that needs access to jars in %{_libdir}/eclipse ?
Comment 1 Alexander Kurtakov 2012-08-10 02:26:54 EDT
there is no easy way to split it.  It shouldn't be a problem for eclipse builds as it's not only problem with swt but with every other jar in the platform.
Also swt.jar is installed in %{_jnidir}/swt.jar which can be used for non-eclipse builds. Is this sufficient or I misunderstood the problem? If there is still a problem please give a concrete example.
Comment 2 Krzysztof Daniel 2012-08-10 02:38:40 EDT
As per comments in https://fedorahosted.org/fpc/ticket/161:

> It is fine to use %{_libdir} for its intended purpose at build-time of noarch packages. It would be very wrong to use it for other than its intended purpose.

> Correct usage in a noarch package could be something like this:

> # We link against libeclipse.so at build time. # At runtime, /usr/bin/eclipse has already loaded the correct version for our arch sed -i 's!/usr/lib/eclipse/libeclipse.so.1!%{_libdir}/eclipse/libeclipse.so.1!g' Makefile

> Incorrect usage in a noarch package could be something like this:

> # We install into the eclipse directory sed -i 's!INSTALLDIR=/usr/lib/eclipse/plugins/!INSTALLDIR=%{_libdir}/eclipse/plugins/!'"


>> The problem that we observed was that during noarch buildtime, for some reason, %{_libdir} did not pointed to the proper Eclipse installation. We guessed that it is %{_libdir} failing to point to an appropriate Eclipse location.

>This would be incorrect.

The last point is that libdir macro should always work, in arch and noarch builds.
Comment 3 Roland Grunberg 2012-08-10 14:06:57 EDT
I took an eclipse plugin (swt-chart) that I know uses %{_eclipse_base} and replaced it's useage with %{_libdir}/eclipse.
(See http://pkgs.fedoraproject.org/cgit/swt-chart.git/tree/swt-chart.spec?id=86982257644f4d0def91a6ecc008eb9184cc9b14#n39)

I did a scratch build with this change, and made sure to hit an x86_64 machine. The result clearly shows that %{_libdir} is resolving to /usr/lib. http://kojipkgs.fedoraproject.org//work/tasks/7321/4377321/build.log.

Am i missing something ? I remember when I tested out the macro, I made sure to hit both primary arch types (x86 and x86_64). For some time now, %{_eclipse_base} has hit both arch types and been able to resolve.
Comment 4 Krzysztof Daniel 2012-08-13 02:13:31 EDT
I have opened clarfication request: https://fedorahosted.org/fpc/ticket/203.
Let's sort this out.
Comment 5 Krzysztof Daniel 2012-08-14 08:36:00 EDT
Summary of the trac ticket:
It would be the best to not use arch macros in a noarch packages at all.
If it is not possible, then it would be good to have the macro expanded at Eclipse build time. 

The question is: in how many projects do we really use %{_eclipse_base} ?
Comment 6 Roland Grunberg 2012-08-14 09:50:33 EDT
I agree with the suggestion made in the ticket. It should work the same way if just expanded at eclipse's build-time.

Tycho needs to use the bundles in eclipse's libdir as part of the target platform when resolving dependencies. This means any noarch package using Tycho for a build doesn't have to worry about it. On the other hand, jfreechart (http://pkgs.fedoraproject.org/cgit/jfreechart.git) currently uses %{_libdir}/java/swt.jar in the ant build, and so the macro would solve their current issue.
Comment 7 Krzysztof Daniel 2012-08-16 05:26:28 EDT
The ticket evolved into:

"Noarch packages must not use %{_libdir} (or any macro
 that contains the literal string "%{_libdir}" in its expansion), since the
 %{_libdir} macro has no useful value in noarch build environments."

"As an exception to this rule, noarch packages may use %configure (which
 uses %{_libdir} to set the --libdir value), but packagers should be very
 careful to ensure that the build/install logic does not actually use this
 value for anything."

The suggested solution for jfreechart is:
  ant -f ant/build-swt.xml \
 -         -Dswt.jar=%{_libdir}/java/swt.jar \
 +         -Dswt.jar=$(build-classpath swt) \
          -Djcommon.jar=$(build-classpath jcommon) \

Is there any other case where we need %{_eclipse_base} ?
Comment 8 Roland Grunberg 2012-08-16 09:28:41 EDT
There's only other cases I can think of :

1) eclipse plugins that use pdebuild (Ideally they should all move to using maven/tycho but perhaps upstream doesn't support this yet?)

I'm not sure how many examples there are, but eclipse-vrapper (currently ftbfs for f18,f19) seems to define '%global eclipse_base   %{_libdir}/eclipse' and then proceed to use that when calling pdebuild (which needs to know the location of the platform). I guess this could be covered by defining the macro at eclipse's build time ?
Comment 9 Krzysztof Daniel 2012-08-16 09:57:30 EDT
But there is already eclipse-pdebuild in bin, which is always right...
Comment 10 Roland Grunberg 2012-08-16 11:36:55 EDT
My mistake. It seems the specfile just needs to be updated. the eclipse-pdbuild script uses 'datadir=`rpm --eval "%{_libdir}"`' to get the directory. This is similar to what Tycho is doing. Is this ok?
Comment 11 Krzysztof Daniel 2012-08-16 11:56:03 EDT
True. I have not checked that. But since it is an arch package, I can change that to contain a symlink to eclipse folder (and I think it will be legal).
Comment 12 Deepak Bhole 2012-08-16 15:48:44 EDT
(In reply to comment #7)
> The suggested solution for jfreechart is:
>  {{{
>   ant -f ant/build-swt.xml \
>  -         -Dswt.jar=%{_libdir}/java/swt.jar \
>  +         -Dswt.jar=$(build-classpath swt) \
>           -Djcommon.jar=$(build-classpath jcommon) \
>           -Djfreechart.jar=lib/jfreechart-%{version}.jar
>  }}}
> Is there any other case where we need %{_eclipse_base} ?

Thanks Kris! I had forgotten that jpackage-utils is now arch-specific. Jfreechart build with above change worked perfectly.
Comment 13 Alexander Kurtakov 2012-12-18 15:32:38 EST
I really haven't followed here but can we close this now ?
Comment 14 Severin Gehwolf 2012-12-19 04:13:14 EST
(In reply to comment #13)
> I really haven't followed here but can we close this now ?

Ok from my point of view. jfreechart builds fine with this for a while now.
Comment 15 Krzysztof Daniel 2012-12-27 09:15:57 EST
Yes - the policy is clear now:
it's ok to have dependency from noarch to arch given that noarch is really noarch - no arch specific paths is hardcoded into it. This means that we should get rid off eclipse_base (and I think we are doing it).

I'm marking it as a 'notabug' because it was rather a clarification request (and fix for jfreechart is just a side effect).

Note You need to log in before you can comment on or make changes to this bug.