working with source rpms [WAS [Is there a howto for building a source rpm?]]
If you want to make any changes to the rpm, the standard procedure would be to install the src.rpm with rpm -ivh, edit the spec file in /usr/src/packages/SPECS and finally build the new rpm with "rpm -bb <spec file>" or "rpm -ba <spec file>" if you want a new src.rpm built with your new edited spec file included.
Anders, Thanks, that does seem to work but is not quite what I was looking for. I guess there is not a HowTo that describes using the *.src.rpm and associated spec files. :( I still have a few questions, maybe you can answer them: (for all of the below, I am working with shadow-4.0.2-47.src.rpm) ---- 1) The above ("rpm -ivh; rpm -ba") is apparently missing some dependency checking. At least on my machine rpm -ba is dying because I don't have ldap.h installed. The dependency on openldap2-devel is in the specfile under both "# neededforbuild" and "# usedforbuild". How do I get rpm to test for it? 2) What is the difference between "# neededforbuild" and "# usedforbuild" in the specfile. 3) If I want to create a patch file of my own, do I just create a shadow-4.0.2-greg.dif file and reference it in the specfile? If so, do I create the diff file with a diff -c like a normal patch? 4) While developing my patches, I want to modify the actual source, compile, and install. The below seems to work, and it installs to /var/tmp/shadow-root, which is nice for initial testing. === # rpm -ivh shadow-4.0.2-47.src.rpm (.src.rpm from the CDs) # cd /usr/src/packages/SPECS # rpm -bp shadow.spec # Apply SuSE specific patches # rpm -bc --short-circuit shadow.spec # Run ./configure as SuSE does # cd /usr/src/packages/BUILD # make source code changes # Invoke local makes as necessary # cd /usr/src/packages/SPECS # rpm -bi --short-circuit shadow.spec # Install === For final testing, how do I get rpm to install to /? Thanks very much, Greg -- Greg Freemyer
On Tuesday 01 April 2003 01:16, you wrote:
If you want to make any changes to the rpm, the standard procedure would be to install the src.rpm with rpm -ivh, edit the spec file in /usr/src/packages/SPECS and finally build the new rpm with "rpm -bb <spec file>" or "rpm -ba <spec file>" if you want a new src.rpm built with your new edited spec file included.
Anders,
Thanks, that does seem to work but is not quite what I was looking for.
I guess there is not a HowTo that describes using the *.src.rpm and associated spec files. :(
I still have a few questions, maybe you can answer them:
(for all of the below, I am working with shadow-4.0.2-47.src.rpm) ---- 1) The above ("rpm -ivh; rpm -ba") is apparently missing some dependency checking.
Yes, there is none. You have to manually make sure the required dependencies are installed.
At least on my machine rpm -ba is dying because I don't have ldap.h installed.
The dependency on openldap2-devel is in the specfile under both "# neededforbuild" and "# usedforbuild".
How do I get rpm to test for it?
You don't. Those are tags used by SuSE's internal build system. You can use them as hints for what you need to install.
2) What is the difference between "# neededforbuild" and "# usedforbuild" in the specfile.
neededforbuild are the direct dependencies that the package uses to compile. As I understand it, the SuSE build system works in a chroot()ed environment. Every time a package is built, a clean environment is created. usedforbuild describes that chrooted environment. As you can see, it includes all the basic packages that are needed for the compile all the way from aaa_base to the top level dependencies.
3) If I want to create a patch file of my own, do I just create a shadow-4.0.2-greg.dif file and reference it in the specfile?
Yes
If so, do I create the diff file with a diff -c like a normal patch?
That is up to you. In the spec file you apply the patch manually, so you can give whatever parameters to patch you like. Look at the %patch statements in the %prep section. Incidentally, the standard usage is to use unified patches (-u). But as I say you can use whatever you prefer.
4) While developing my patches, I want to modify the actual source, compile, and install.
The below seems to work, and it installs to /var/tmp/shadow-root, which is nice for initial testing. === # rpm -ivh shadow-4.0.2-47.src.rpm (.src.rpm from the CDs) # cd /usr/src/packages/SPECS # rpm -bp shadow.spec # Apply SuSE specific patches # rpm -bc --short-circuit shadow.spec # Run ./configure as SuSE does # cd /usr/src/packages/BUILD # make source code changes # Invoke local makes as necessary # cd /usr/src/packages/SPECS # rpm -bi --short-circuit shadow.spec # Install === For final testing, how do I get rpm to install to /?
You could change the build root in the spec file. But I always build the binary rpm and install it as per normal when I work with them. When I make changes in rpms, here's my procedure rpm -ivh rpm -bp edit source files and create diffs, edit the spec file to use those diffs rpm -bb rpm -Uvh on the binary rpm I'm sure there are other ways of doing it, with the "interrupted style" build you describe above, but this is the way I do it and it seems to work. I haven't really looked at your method, so I can't discuss it. regards Anders
Anders Johansson <andjoh@rydsbo.net> [Tue, 1 Apr 2003 01:28:52 +0200]:
neededforbuild are the direct dependencies that the package uses to compile.
Better said, those are the packages needed to build the package. These are either packages needed to compile the package or are needed for things like making symlinks etc.
As I understand it, the SuSE build system works in a chroot()ed environment.
Correct.
Every time a package is built, a clean environment is created.
Also correct.
usedforbuild describes that chrooted environment. As you can see, it includes all the basic packages that are needed for the compile all the way from aaa_base to the top level dependencies.
Yes, you could regard usedforbuild as an information about what was installed.
Incidentally, the standard usage is to use unified patches (-u). But as I say you can use whatever you prefer.
There is no standard usage. Some projects prefer unified diffs, others like the GCC project prefer context diffs, at least for larger diffs.
I'm sure there are other ways of doing it, with the "interrupted style" build you describe above, but this is the way I do it and it seems to work. I haven't really looked at your method, so I can't discuss it.
For building SuSE rpms I'd suggest to give the build script a try. The package build.rpm contains a script that builds a chroot environment using the CDs/DVDs. cheers Philipp -- Philipp Thomas work: pthomas@suse.de Development SuSE Linux AG private: pth@t-link.de
Op woensdag 2 april 2003 00:34, schreef Philipp Thomas:
For building SuSE rpms I'd suggest to give the build script a try. The package build.rpm contains a script that builds a chroot environment using the CDs/DVDs.
Interesting :) So, I gave it a try.... # env BUILD_RPMS=/data2/suse build logging output to /var/tmp/build-root/.build.log... pilchard started "build " at Wed Apr 2 01:04:09 CEST 2003. Using BUILD_ROOT=/var/tmp/build-root Using BUILD_RPMS=/data2/suse ... preinstalling glibc... can not find glibc.rpm... exit. But: suse> find /data2/suse -name "glibc-2*" /data2/suse/i586/glibc-2.2.5-151.i586.rpm /data2/suse/i686/glibc-2.2.5-152.i686.rpm -- Richard Bos Without a home the journey is endless
Op woensdag 2 april 2003 00:02, schreef Richard Bos:
But: suse> find /data2/suse -name "glibc-2*" /data2/suse/i586/glibc-2.2.5-151.i586.rpm /data2/suse/i686/glibc-2.2.5-152.i686.rpm
Renaming glibc-2.2.5-151.i586.rpm to glibc-2.2.5-151.i586.RPM resolved this issue... -- Richard Bos Without a home the journey is endless
participants (4)
-
Anders Johansson
-
Greg Freemyer
-
Philipp Thomas
-
Richard Bos