the source repo src.rpm files, ummm?

In the repo hierarchy there is the “source” directory which has a pile of xxx.src.rpm files. I’m unsure how fully ‘program source’ they are or using them.

We know many 3rd party apps and distros have the source code available in compressed tars or such and you get those and extract them to wherever you want, then there is a ‘./configure’ file included to begin the compile routine.

Suse uses the rpm suffix and you need to use rpm on command line which extracts them to a directory under /usr/src.

What I see there are some suffix .pl, .sh and .patch files a few others and at least one xxx.tar.bz2, no configure. If I extract that bz2 file I see what really is the expected source code with a configure file - usually. I pulled down a number of src.rpms some not having a configure.

Right, I looked through the rpm, rpmbuild mans but am unsure what exact routine to follow.

For one app, with the included bz2 file extracted I got hold of the matching version source from the actual developer website. The resultant pre-compile directories/files of each were identical.

I did the ‘configure/make/install’ routine for both and probably got the same working app result. I mean the app worked and the binaries identical. This suggests I could just use the bz2 file content alone from any Suse src.rpm I get.

Question: Is this a reasonable conclusion?

Further reading suggests that I really need to use ‘rpmbuild’ with some options resulting in either: a source tree with applied patches (those .patch files??), actually installed or a final rpm.

This is the confusing area, concerning rpmbuild. I tried doing the prepare a source tree bit but I got error messages that I needed a pile of xxx-devel libraries. I’m not wanting to “build an rpm” file as such or play at developing apps from source.

Question: I redid the prep plus nodeps (rpmbuild --nodeps -bp) and this gave a no-error source with configure which compiled fine, so is this nodep method ok or…?

How come I can do a “normal” compile routine from a source and not get errors about devel libs?

I’ll try to compress my confusion on how to properly use the src.rpm files:

It seems I need to use ‘rpm’ to install a src.rpm to the /usr/src area. Then I need to use ‘rpmbuild’ to get the source tree with a ‘configure’ for starting the compile but this can give me depend errors which I don’t get using the content of the .bz2 from the src.rpm.

Clarification on method appreciated

Use ‘sudo zypper si <package>’
It will install <package>.src.rpm and all build dependencies.

thanks anyway, but still looking for specific answers :slight_smile:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

openSUSE use rpm as packages, so if you want a source code package of
an apps, it comes as rpm that provide the tar.bz file with the source,
once you uncompress the source you can see what method is the correct
for compile it


VampirD

Microsoft Windows is like air conditioning
Stops working when you open a window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkwjY7sACgkQJQ+0ABWtaVmR0ACgnx3VGRKyDJ+s9p+h6920klnI
a50AoJrK2OEc4fS8NQ+8/YkiNAhowGPO
=Eyu/
-----END PGP SIGNATURE-----

Source RPM package are a layer of wrapping around upstream packages together with any relevant patches. If you have the srpm, then using rpmbuild would be the preferred method of building since it will look out for the dependencies for you. Not every upstream package uses ./configure as the prep procedure, but in any case the srpm contains the appropriate scripts to prep the sources.

Building the sources yourself by unpacking the tar.bz2 tarballs and doing ./configure will not get around the need to have the dependencies installed. You will just hit problems later when configure cannot find the prerequisites or the compile fails. The srpm has all these things worked out ahead of time.

So no point trying to bypass rpmbuild if you have the srpm. The configure method is used when there is no srpm and you have to start from the upstream package and satisfy all the dependencies manually.

thanks,

the thing is where I found that “development” libs were given as dependencies starting with the “full” srpm, whereas just using the source didn’t mention them but did for non-develop types. . On the one hand I can understand the requirement but disk space or not, I’m not keen on bloating out. :slight_smile: