Hello List,
With 11.2 and kde 4.3.1, I just built a source rpm manually, Along the way I tried to use the package manager unsuccessfully.
Am I correct to conclude that the package manager works on object rpms only? Heboland.
Hello List,
With 11.2 and kde 4.3.1, I just built a source rpm manually, Along the way I tried to use the package manager unsuccessfully.
Am I correct to conclude that the package manager works on object rpms only? Heboland.
It works on src.rpms, but those are installed under /usr/src/packages, typically the code going into SOURCES and the spec files going into SPECS. You can then modify and rebuild from there.
Thank Ken,
I did built the source rpm manually in /usr/src… Heboland
Ok I Think the OP is a bit confused.
You install a Source RPM. The rpm program is used, thus the rpm database knows about the “SOURCE” package. If you then build the package manually the rpm database does not know this so in general Yast/zypper/rpm etc does not know that this binary exists. By building the binary from source you have taken full responsibility of maintaining it by hand. The source package however can still be maintained by Yast/zypper/rpm
Yes, but rpmbuild just leaves the RPM in one of RPMS/{noarch,x86_64,i686}. It doesn’t install the package. As gogalthorp says, when you build you own object RPM package, it’s all in your hands.
Actually src.rpms are not recorded in the database when “installed”. They are just unpacked.
Thanks gogalthorp, ken,
I first tried to install the source rpm (srpm) with the package manager (PM). It didn’t seem to understand it.
So as root I manually installed the srpm. That unpacked the srpm in the /usr/src/package directories.
I added the SPEC directory as a repository and PM couldn’t find the spec file. When as root I manually built the spec file there were two missing library dependencies.
With the PM, I added the libraries, then manually built the “object” rpms from the spec.
Next I added the RPMS directory as a repository, then installed the two rpms with the PM.
I would have preferred to use the PM to resolve the spec file dependencies, but it seems not to understand a spec file.
I have what I wanted to end up with, but I was hoping there was a less manual way to accomplish it. Heboland
BTW:
NEVER (re)build RPM packages as root!
On 04/30/2010 03:26 PM, Akoellh wrote:
>
> BTW:
>
> NEVER (re)build RPM packages as root!
An anecdote on why it is bad practice. The build system for the kernel
is extremely complicated, and there are bugs in it from time to time.
One such bug in the past tried to delete /dev/null - an extremely
important pseudofile. If you were building that kernel as an
unprivileged user, you got a permissions error. Those people that were
building as root ended up with a system that could no longer boot!
Hi
Also the permissions on the drectories below /usr/src/packages need to
be checked they should be 1777.
–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.45-0.1-default
up 15 days 10:09, 5 users, load average: 0.31, 0.35, 0.35
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 195.36.15
This should be set via permissions.
OTOH I didn’t like the settings made by permissions.easy and 1777 ist too “open” for me, so one can set this to:
# rpm subsystem:
/usr/src/packages/SOURCES/ root:trusted 1775
/usr/src/packages/BUILD/ root:trusted 1775
/usr/src/packages/BUILDROOT/ root:trusted 1775
/usr/src/packages/RPMS/ root:trusted 1775
/usr/src/packages/RPMS/alpha/ root:trusted 1775
/usr/src/packages/RPMS/alphaev56/ root:trusted 1775
/usr/src/packages/RPMS/alphaev67/ root:trusted 1775
/usr/src/packages/RPMS/alphaev6/ root:trusted 1775
/usr/src/packages/RPMS/amd64/ root:trusted 1775
/usr/src/packages/RPMS/arm4l/ root:trusted 1775
/usr/src/packages/RPMS/athlon/ root:trusted 1775
/usr/src/packages/RPMS/geode/ root:trusted 1775
/usr/src/packages/RPMS/i386/ root:trusted 1775
/usr/src/packages/RPMS/i486/ root:trusted 1775
/usr/src/packages/RPMS/i586/ root:trusted 1775
/usr/src/packages/RPMS/i686/ root:trusted 1775
/usr/src/packages/RPMS/ia32/ root:trusted 1775
/usr/src/packages/RPMS/ia64/ root:trusted 1775
/usr/src/packages/RPMS/mips/ root:trusted 1775
/usr/src/packages/RPMS/ppc/ root:trusted 1775
/usr/src/packages/RPMS/ppc64/ root:trusted 1775
/usr/src/packages/RPMS/ia32e/ root:trusted 1775
/usr/src/packages/RPMS/pentium3/ root:trusted 1775
/usr/src/packages/RPMS/pentium4/ root:trusted 1775
/usr/src/packages/RPMS/powerpc64/ root:trusted 1775
/usr/src/packages/RPMS/s390/ root:trusted 1775
/usr/src/packages/RPMS/s390x/ root:trusted 1775
/usr/src/packages/RPMS/sparc/ root:trusted 1775
/usr/src/packages/RPMS/sparcv9/ root:trusted 1775
/usr/src/packages/RPMS/sparc64/ root:trusted 1775
/usr/src/packages/RPMS/x86_64/ root:trusted 1775
/usr/src/packages/RPMS/armv4l/ root:trusted 1775
/usr/src/packages/RPMS/hppa/ root:trusted 1775
/usr/src/packages/RPMS/hppa2.0/ root:trusted 1775
/usr/src/packages/RPMS/noarch/ root:trusted 1775
/usr/src/packages/SPECS/ root:trusted 1775
/usr/src/packages/SRPMS/ root:trusted 1775
in /etc/permissions.local and add all users being allowed to build RPMs to the “trusted” group.
Another possibility would be to create a new, custom group like “rpmbuilders” and use that group instead of “trusted”.
Third and maybe most elegant solution, create your own RPM-subsystem for building packages in your $HOME as described here:
Is it possible to install package without its dependency ? - openSUSE Forums
Thank you Akoellh, malcolmlewis, lwfinger,
This thread is getting complicated for it’s location. I’ll leave it to you guys if it should be moved elsewhere.
I understand what the three of you wrote, but I want to take this back a step. My rpm build enviromment was installed at my request along with the other opensuse 11.2 packages some time ago during the 11.2 installation.
Opensuse 11.2 created the directories RPMS, SPEC, etc with root-root privileges. If now i should change the privileges to root-trusted, why didn’t they install that way.
It seems to me that my actions as root (install source rpm, rpmbuild specfile) should only affect the permissions of the files, manpages, etc resulting from the build.
The package manager successfully installed the resultant object rpms created. Where is the harm here? Heboland