| Summary: | nagios-plugins binary ebuild fails | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ti Leggett <leggett> |
| Component: | New packages | Assignee: | Gentoo Netmon project <netmon> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | mathias.gug |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Fix to chown after pkg is installed. | ||
Created attachment 37762 [details, diff]
Fix to chown after pkg is installed.
Could you try this patch for nagios-plugins-1.3.1-r1.ebuild ?
It moves the chown instruction to pkg_postinst, rather than pkg_preinst.
The chown should be in src_install. and the enewuser/group should be in pkg_setup... fixed in portage. enewuser/group should not be in pkg_setup - see bug 58526. It should be in pkg_{pre|post}inst. Well, I can't chown nagios on src_install if I don't do it in pkg_setup. I agree. But if you create the nagios user and group in pkg_setup, the nagios user and group will not be created during a binary installation. So the creation should be also done in pkg_pre to fix the binary installation. |
Trying to install a binary ebuild of nagio-plugins fails. The problem is two fold. First, for some reason the package does not create /var/tmp/portage/nagios-plugins-1.3.1-r1/image/ which means the binary tar ball cannot be untarred. Second, even if you create /var/tmp/portage/nagios-plugins-1.3.1-r1/image/, the binary tar ball is not untarred. In order for the binary to be successfully emerged, you have to: * make the /var/tmp/portage/nagios-plugins-1.3.1-r1/image/ directory * fetch the binary package * manually untar the binary package to /var/tmp/portage/nagios-plugins-1.3.1-r1/image/ * then, and only then, can you successfully emerge the package This does not seem to be the case with other nagios binary packages I've created, or for that matter, any other package I've made a binary. This was the case for nagios-plugins-1.3.1 as well as nagios-plugins-1.3.1-r1 (1.3.1 also had the problem of not creating the nagios user and group which has been fixed in r1). Nothing in the ebuild I can see would lead me to this behavior. Reproducible: Always Steps to Reproduce: 1. host1$ emerge -qb nagios-plugins 2. host2$ emerge -qGK nagios-plugins Actual Results: >>> emerge (3 of 4) net-analyzer/nagios-plugins-1.3.1-r1 to / >>> extracting info >>> extracting nagios-plugins-1.3.1-r1 >>> Merging net-analyzer/nagios-plugins-1.3.1-r1 to / chown: cannot access `/var/tmp/portage/nagios-plugins-1.3.1-r1/image//usr/nagios/libexec': No such file or directory !!! ERROR: nagios-plugins-1.3.1-r1/nagios-plugins-1.3.1-r1 failed. !!! Function pkg_preinst, Line 59, Exitcode 1 !!! Failed Chown of /var/tmp/portage/nagios-plugins-1.3.1-r1/image//usr/nagios/libexec Expected Results: Successful binary emerge In the above, host1 is my central binary build machine and repository. host2 is some client on my network that has host1 as it's PORTAGE_BINHOST. I label this as a Major bug since a) it's the only package that I've ever seen do this (out of some 450 packages I've made binaries of) and b) it's a major pain for me because I manage some 50+ machines that all run gentoo and all need to be monitored with nagios. When I build a new machine or upgrade nagios-plugins, I have to go to each machine and hand install the package.