What's the %{_eclipse_base} macro defined as? Macros are expanded at package build time so the macro would not be trivial.

I see this in eclipse/macros.eclipse:

{{{
%_eclipse_bits %(rpm --eval %{__isa_bits} | sed 's/32//')
%_eclipse_base %{_prefix}/lib%{_eclipse_bits}/eclipse
}}}

Which looks like it's simply reimplementing %{_libdir} poorly (running rpm from within a build is a bad idea).

I think I see two choices here:

1) Patch noarch eclipse plugin build scripts to properly find the dependent plugins whether they're in /usr/lib or /usr/lib64

2) Make all eclipse plugin packages arch-specific. This is what most guidelines have done in the past (Jesse Keating once proposed a more generalized form of this for all packages, in fact).

After much discussion today, we're not even sure if toshio's option 1 would be sufficient. The proposed macro usage would not solve the problem, since macros are evaluated at buildtime, not at install time, and it would also break the rule of "do not exec rpm within rpm". Honestly, the only real option here that doesn't involve violating the laws of physics is to make all such packages arch-specific.

We reviewed the pdebuild changes separately, and they were approved. (+1:5, 0:0, -1:0).

Replying to [comment:3 spot]:

After much discussion today, we're not even sure if toshio's option 1 would be sufficient. The proposed macro usage would not solve the problem, since macros are evaluated at buildtime, not at install time, and it would also break the rule of "do not exec rpm within rpm". Honestly, the only real option here that doesn't involve violating the laws of physics is to make all such packages arch-specific.

Well, the packages are noarch definetely. It just happens that they have arch-specific dependencies to be build and the path is important. I'm not going to argue about _libdir usage noarch packages %build section (it is still incorrect from my POV) but this is the way we found to successfully evaluate _libdir when the macro doesn't work for us. Would a uname solution instead of rpm eval fix the issue?

We reviewed the pdebuild changes separately, and they were approved. (+1:5, 0:0, -1:0).

Please give us an example of where %_libdir is insufficient for your needs so that we can play around with fixes to the problem.

This post explains our problem: http://lists.fedoraproject.org/pipermail/devel/2012-April/165179.html

Replying to [comment:4 akurtakov]:

Replying to [comment:3 spot]:

Honestly, the only real option here that doesn't involve violating the laws of physics is to make all such packages arch-specific.

Well, the packages are noarch definetely. It just happens that they have arch-specific dependencies to be build and the path is important.

Right, what you mean is:

The packages ship the same bits on i386 and x86_64, but the bits are located in different places and/or have different rpm requirements.

...this means they are arch specific and you can't do anything to ship them as noarch. If you want to ship them as noarch then what is downloaded/installed on an i386 has to be identical to what is downloaded/installed on a ppc64 or x86_64 client (Ie. the exact same rpm package).

If space is a major concern there are hacks that can be done so that "all" the data is in a noarch package which is shared ... or you can fix eclipse so that it can take true noarch packages. But what we have now isn't it.

Replying to [comment:7 james]:

Replying to [comment:4 akurtakov]:

Replying to [comment:3 spot]:
Right, what you mean is:

The packages ship the same bits on i386 and x86_64, but the bits are located in different places and/or have different rpm requirements.

...this means they are arch specific and you can't do anything to ship them as noarch. If you want to ship them as noarch then what is downloaded/installed on an i386 has to be identical to what is downloaded/installed on a ppc64 or x86_64 client (Ie. the exact same rpm package).

To be specifc - and be sure that I get things right - more explanations and a detailed example:

Eclipse itself contains native code and java facades for it. It is an arch-specific package, no doubt, and therefore it goes into /usr/lib or usr/lib64 folders.
Now any java package that extends Eclipse requires to know eclipse location at built time in order to access that java facades (and other libraries too). The java package does not need 32 or 64 bit, but, despite being noarch, it needs two things:
installed Eclipse match the architecture of koji builder
know the path to the Eclipse.
The java package built on 32 bit builder is identical to the one built on 64 bit, and can be used on both platforms.

Are you saying that the java package should be made an arch package?

This post explains our problem: http://lists.fedoraproject.org/pipermail/devel/2012-April/165179.html

This was less helpful than I hoped -- the build.log has been garbage collected and someone has built a new version of that package using the same NVR so I can't resubmit the build to get the build.log. If you could produce the SRPM for that build, I could take a look at it in a scratch build or something.

Replying to [comment:8 kdaniel]:

To be specifc - and be sure that I get things right - more explanations and a detailed example:

Eclipse itself contains native code and java facades for it. It is an arch-specific package, no doubt, and therefore it goes into /usr/lib or usr/lib64 folders.
Now any java package that extends Eclipse requires to know eclipse location at built time in order to access that java facades (and other libraries too). The java package does not need 32 or 64 bit, but, despite being noarch, it needs two things:

Up to here, the package could be arch-specific or noarch although it might need to have its build scripts modified. Beyond here we get into trouble which might be me not understanding you or might be actual problems.

• installed Eclipse match the architecture of koji builder

This would require the package to be arch-specific. Since you're also saying that the built packages are identical below, I have the feeling that I'm not understanding what you mean with this bullet point, though.

• know the path to the Eclipse.

This might not. If it needs to know the path to Eclipse at buildtime only, then %{_libdir} will work. If it needs to know the path to eclipse at runtime then it can be made to work if the code can check both /usr/lib64/[...] and /usr/lib/[...] at runtime for the code it needs (probably needs to check in that order as /usr/lib64/[...] shouldn't exist on a x86 machine but /usr/lib/[...] may exist on a multilib x86_64 machine).

The java package built on 32 bit builder is identical to the one built on 64 bit, and can be used on both platforms.

Are you saying that the java package should be made an arch package?

If the package is only needing some special handling at build time then it is possible (but not 100% certain) that the package can be noarch. You may need to patch the upstream code to make this work, though. The macro proposed here doesn't look like it has any advantage over %{_libdir} though -- as I said in an earlier comment, it just appears to reimplement %{_libdir} poorly.

More information about dependencies:
Eclipse has some arch specific libraries. To build 3rd party Eclipse plugin, you need to know the path to Eclipse (buildtime dependency Eclipse plugin->Eclipse). At runtime, the dependency is reversed. Eclipse looks for a place with all plugins and load them. Since plugins are generally noarch, they can be easily found in the /usr/share/eclipse (no issue at runtime).

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. Message http://lists.fedoraproject.org/pipermail/devel/2012-April/165292.html confirmed that when bulding noarch packages both %{_libdir} and %{_isa} macros are useless.

For me it was either %{_libdir} failing to resolve architecture properly or koji failing to install Eclipse matching builder architecure (f.e. building noarch on x86_64 somehow installed eclipse x86).

With the appearance of the "poor" eclipse_base macro, the problem got solved - so in my eyes it was %{_libdir}'s fault.

In the meantime we managed to link Eclipse build script into %{_bindir}, so the problem got workarounded (or solved) for the majority of packages. There may be still some left, though, so I'd like to get some agreement here, whether it should or should not be ok to use %{_libdir} for build-time dependencies in noarch packages.

Replying to [comment:10 kdaniel]:

More information about dependencies:
Eclipse has some arch specific libraries. To build 3rd party Eclipse plugin, you need to know the path to Eclipse (buildtime dependency Eclipse plugin->Eclipse). At runtime, the dependency is reversed. Eclipse looks for a place with all plugins and load them. Since plugins are generally noarch, they can be easily found in the /usr/share/eclipse (no issue at runtime).

So, here's what I'm reading you as saying (using non-real librarynames/paths)

eclipse has an arch specific library, let's say %{_libdir}/eclipse/libeclipse-plugin.so.1

At build time, the plugin build script needs to look in %{_libdir}/eclipse/ to find and link against it.

The plugin build script places the plugin into %{_datadir}/eclipse/plugins/myplugin.jar

At runtime, /usr/bin/eclipse looks in %{_datadir}/eclipse/plugins/ to load all plugin files.

Does that sound like a good summary of the pieces involved and the %{_libdir} vs noarch (%{_datadir}) paths?

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.

Message http://lists.fedoraproject.org/pipermail/devel/2012-April/165292.html confirmed that when bulding noarch packages both %{_libdir} and %{_isa} macros are useless.

This is a misinterpretation of what Panu is saying. Or, alternately, you could view it as Panu misinterpreting the question that you asked and therefore answering some other question.

For me it was either %{_libdir} failing to resolve architecture properly or koji failing to install Eclipse matching builder architecure (f.e. building noarch on x86_64 somehow installed eclipse x86).

AFAIK, the builders do not have access to the x86 rpms. The x86 rpms are added to the yum download repositories at a later stage. koji only has access to the rpms for its arch and noarch.

With the appearance of the "poor" eclipse_base macro, the problem got solved - so in my eyes it was %{_libdir}'s fault.

Since the bad eclipse_base macro does the same thing that %{_libdir} does, it means that your problem was unrelated to the use or non-use of that macro. It worked when you changed it because you were hitting a different builder (for instance, an x86 builder instead of an x86_64 builder) or a problem in another package was fixed or the way you implemented using the eclipse_base_macro in your spec file propogated to a different portion of your build scripts than the way you implemented using %{_libdir}.

In the meantime we managed to link Eclipse build script into %{_bindir}, so the problem got workarounded (or solved) for the majority of packages. There may be still some left, though, so I'd like to get some agreement here, whether it should or should not be ok to use %{_libdir} for build-time dependencies in noarch packages.

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/!'

I think this one an be closed right not. We will remove the eclipse_base macro.