How do you build an RPM from source code? I’ve never tried it before, but something on my phone made me wonder.
I mean, there are tutorials all over the Internet for this. Is there something specific you’re trying to build?
Otherwise, I’d suggest starting by reading the existing documentation. 
Aside from the information provided by @hendersj you could always browse https://build.opensuse.org/ and pick a project and look at the rpms there.
1 Like
I know how to install a package from source. I haven’t built an RPM for a local repository. I thought there might be special packages required for doing this.
Yes, and I’m not saying “read the documentation for installing packages”, I’m saying “read the documentation for building packages”. As Malcolm said, build.opensuse.org contains lots of examples you can look at, as well as a link at the bottom of the page to the documentation on how to use the service to build RPMs.
1 Like
There are no separate tools to build a .rpm but likely because there are quite some things that go into a .rpm.
To build a rpm package, make osc work, see:
https://en.opensuse.org/openSUSE:OSC
After that you can use “osc mkpac” to create a new package, that is it creates a new package in your home project, home:jonc. Then add a valid .spec file and hit “osc build” and it will locally build the package, no need to check things in.
1 Like
Thanks for sharing what was found on the Internet, put in some big-big matrix and (for now) retrieved without costs.
I still think the “osc build” route is easier.
If you are building locally, install package “build” .
IMO the easiest way to check that all is working is to rebuild some package from their .srpm source.
Then you can install that .srpm, modify the .spec, update the source (most times some .tar.gz or tar.bz), or add some patch or configuration according to your needs, and build from .spec.
Maybe we are referring to different things, or I don’t understand your statement, but there have been tools to build a .rpm in SuSE at least for two decades.
Funny thing … there’s actually a pattern for it which installs rpm-build (amongst other things) … I use it all the time
dart@widowmaker:~> zypper se pattern:rpm
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-----------------+-----------------------+--------
i+ | devel_rpm_build | RPM Build Environment | pattern
dart@widowmaker:~> ls -l rpmbuild/
total 0
drwxr-xr-x. 1 dart dart 0 Jul 27 14:04 BUILD
drwxr-xr-x. 1 dart dart 0 Jul 27 14:04 OTHER
drwxr-xr-x. 1 dart dart 24 Jul 27 04:02 RPMS
drwxr-xr-x. 1 dart dart 2686 Jul 27 13:40 SOURCES
drwxr-xr-x. 1 dart dart 1340 Jul 28 12:25 SPECS
drwxr-xr-x. 1 dart dart 58 Jul 27 14:04 SRPMS
dart@widowmaker:~>
You also need rpmdevtools
dart@widowmaker:~> zypper se rpmdevtools
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-------------+-----------------------+--------
i | rpmdevtools | RPM Development Tools | package
dart@widowmaker:~>
The command to setup the rpmbuild tree is rpmdev -setuptree
1 Like
Sorry got an extra space in there … rpmdev-setuptree … one command no space
Fully with you. Not packaging atm, but have both done the “old” way and with osc/OBS. With osc I would these days even go for a distrobox instead of polluting my system with more and more -devel packages.
1 Like
Same. What’s more, with osc, you don’t need to use the build service - you can still do the entire build locally (and that’s recommended when you’re testing a package anyways AFAIK - it generally is faster than waiting for a build worker to pick the job up).
1 Like
I’ve never used osc. From a learning process perspective, does using osc hide details that would be important to know? Or can a user learn the same thing easily?
Having built code (but not necessarily packages) before, it was pretty easy to use, and everything is logged so you can review the compilation process.
Having some experience in compiling code and understanding dependencies is something I would consider essential. Not necessarily coding experience, though obviously that is helpful for diagnosing issues at build time.
Thank you. My use case for building packages is mostly when I need some compile options, or patches, or a newer/unreleased version that solves a problem, that are not (or not yet) included in the official build. Just a few times a year.
Usually for something like that, it’s easiest to take a pre-existing package and modify it. I’ve been known to do that on occasion, and in one case, I submitted the update to Factory for review. Usually it’s just something for my own amusement/amazement, though. 
Learning how to apply patches using OSC is a worthwhile exercise - rather than patching the code, incorporating the patch diff into the files and applying it at compile time is a skill that’s definitely worth learning.
1 Like
Install osc and grab your favorite package from its devel package and build with osc build. (also exists as distrobox image to avoid installing dependencies: https://en.opensuse.org/Distrobox)
2 Likes