Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[vdb]

Somebody must know this, but I have not found a good answer to this one:
How can I create a RPM file of the WxWidget 2.6.3 source files?

I am using a rather standard rpmbuild environment on a Mandriva 2006.0 box. This works for aMule, it neatly puts a RPM in the rpm/RPMS/i686 directory when I use the standard spec file delivered with the aMule sources.

However, when I do the same for the WxWidget sources, nothing gets put in the i686 directory, nor in the i586 or i386 or noarch directories.

I can't find any (relatively) clear instructions on the internet on how I must handle the WxWidgets spec file to get to the desired result. Anybody here that can help me out perhaps?

[Gerd78]

The spec files distributed with wxWidgets are broken, and parts of wxWidgets' own build system are broken in a way that affects building packages - specifically, handling the DESTDIR variable is incorrect:

http://sourceforge.net/tracker/index.php?func=detail&aid=1453091&group_id=9863&atid=109863

You have to write your own spec file and you have to fix the DESTDIR issue, either by patching Makefile.in or by adjusting the /usr/bin/wx-config symlink manually within the spec file.

For completeness, here is the GNU coding standard which specifies how DESTDIR should be handled:

http://www.gnu.org/prep/standards/standards.html#DESTDIR

Prepending the variable DESTDIR to each target in this way provides for staged installs, where the installed files are not placed directly into their expected location but are instead copied into a temporary location (DESTDIR). However, installed files maintain their relative directory structure and any embedded file names will not be modified.

The target of a symlink is an embedded file name and must not include the value of DESTDIR; if it does, rpmbuild detects that and aborts the build.

[wardevil]

Test this one if you want...
This spec divides the rpms into wx-base and wx-gtk2 so, if you want to be as monolithic library rpm then u must change it.
This spec if for mandrake 10 version.

Let me know if any problem or questions about it....

Cheers.....

[Gerd78]

Hi wardevil,

there are upgrade problems with this spec file.

See:

Code: [Select]

%post devel
# link wx-config when you install RPM.
%if %{unicode}
    ln -sf %{_libdir}/wx/config/%{wxconfig} %{_bindir}/wx-config
%endif
# link wx-config with explicit name.
ln -sf %{_libdir}/wx/config/%{wxconfig} %{_bindir}/%{wxconfiglink}
/sbin/ldconfig

[...]

%preun devel
%if %{unicode}
    rm -f %{_bindir}/wx-config
%endif
rm -f %{_bindir}/%{wxconfiglink}The execution order of rpm scriptlets is not what you probably expect. This spec file assumes that the execution order during upgrades is:

%preun scriptlet of the old (uninstalled) package
%postun scriptlet of the old (uninstalled) package
%pre scriptlet of the new (newly installed) package
%post scriptlet of the new (newly installed) package

But rpm doesn't erase the old and then install the new package; it installs the new one first and then erases the old one. This is intended to be a feature, not a bug, to make sure that at least one version is always installed and that there is not even a nanosecond where none of both versions is installed.

Therefore the actual execution order is:

%pre scriptlet of the new (newly installed) package
%post scriptled of the new (newly installed) package
%preun scriptlet of the old (uninstalled) package
%postun scriptlet of the old (uninstalled) package

The result is quite simple: During initial installation, everything works OK, but during upgrades the wx-config will be lost because "rm -f" is executed *after* "ln -sf" and *not* before.

You can find more information and the solution here:

http://www-128.ibm.com/developerworks/library/l-rpm3.html

[wardevil]

I just adapted a litle to fit my needs but that spec is original from the wxGTK tarball with of course the modifications made by me....

Cheers.....

[Gerd78]

Yeah, I know, it looks very familiar, my first impression was that I've already seen this code before...

This is not a personal attack against anyone, but the upgrade problem is still there no matter who wrote it. You can verify it by rebuilding the packages with a bumped release number and performing a regular upgrade (rpm -U). The wx-config symlinks will be gone afterwards.

My recommendation is: Don't use rpm scriptlets at all, using them is not necessary here. Just include the wx-config symlink directly in the file list of the -devel package - keeping things as simple as possible is the best.

Another solution is using the update-alternatives framework. This originates from Debian, but was ported to rpm by Mandriva and is available in most modern distros. There is not much documentation about it, but you can copy some code from jpackage.org RPMs - they are heavily using the update-alternatives framework.

As a last resort you can use the low-level solution as documented in the IBM developerWorks article: Wrap the removal code into an upgrade test.

Code: [Select]

%post devel
if [ "$1" -eq "1" ] ; then
# link wx-config when you install RPM.
%if %{unicode}
    ln -sf %{_libdir}/wx/config/%{wxconfig} %{_bindir}/wx-config
%endif
# link wx-config with explicit name.
ln -sf %{_libdir}/wx/config/%{wxconfig} %{_bindir}/%{wxconfiglink}
fi
/sbin/ldconfig

[...]

%preun devel
if [ "$1" -eq "0" ] ; then
%if %{unicode}
    rm -f %{_bindir}/wx-config
%endif
rm -f %{_bindir}/%{wxconfiglink}
fi"Someone" should report this to the wxWidgets people, but at the moment I don't intend to do it because I disagree with the overall design of these spec files. Their approach is overly complex, much more than it has to be.

Another reason is that there are even more illogical things in it. For example, running /sbin/ldconfig after installing development sub-packages is completely unnecessary - /sbin/ldconfig is intended to be run after installing a shared object which has an SONAME only, but development sub-packages don't contain any shared libraries at all.

This does not break anything, but it is still highly questionable and, sorry to say, not a good coding practice. And the placement of comments which refer to conditional code is incorrect, and the code in %preun should be in %postun to avoid troubles in unforeseen situations, and, and, and...

[wardevil]

Yes.....i have been upgrade issues with that too...but if i remove the old rpms and install the new ones will work....  
Nice work tho...

"Someone" should report this to the wxWidgets people, but at the moment I don't intend to do it because I disagree with the overall design of these spec files. Their approach is overly complex, much more than it has to be.

LOL....you should see a kernel spec file from mandriva....  

Cheers....

[vdb]

Thanks for all this help guys, I'll have to give it a try when I have some evening time this week, but I'm sure with all these pointers it shouldn't be too much of an issue anymore.  

[vdb]

Just to let you know, the spec file by Wardevil did the trick, I now have a lot of nice rpms which will be used constantly in the future.

Thanks for the help guys.