The pre-install target is run as the user that invoked 'make install'. If this user is not root, they can't create files or directories under ${PREFIX}. Fix: Use pre-su-install instead: -pre-install: +pre-su-install: # # Handle the loading of the linux loadable kernel module if required. @${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL--zuzfqDkQmKDQFui1NczG8bAGubF8E9SC2YOwg5nX5mgRkP4L Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" Index: Makefile =================================================================== RCS file: /usr/cvs/ports/emulators/linux_base-8/Makefile,v retrieving revision 1.102 diff -u -r1.102 Makefile --- Makefile 15 Mar 2005 05:25:17 -0000 1.102 +++ Makefile 6 Apr 2005 17:20:19 -0000 @@ -97,7 +97,7 @@ LINUX_ELF= 3 PREVIOUS_ELF!= /sbin/sysctl -n ${FALLBACK_ELF_MIB}
Responsible Changed From-To: freebsd-ports-bugs->emulation Over to maintainer(s).
I ran into the same problem as John. Unfortunately although the patch allows a non-root user to start the installation, it is failing for me on 5.4-RC3/amd64 with an up to date ports collection. I think the problem is related to the handling of ARCH, in particular the following section in the Makefile: .if (${ARCH} == "amd64") LATEST_LINK:= ${LATEST_LINK:C/linux/linux32/} ARCH= i386 FALLBACK_ELF_MIB= kern.elf32.fallback_brand RPMFLAGS+= --noscripts .else FALLBACK_ELF_MIB= kern.fallback_elf_brand .endif When we su to do something a sub make process is invoked as part of the su command to perform the privileged task(s). I believe this invocation is inheriting the altered ARCH setting, which then breaks the installation of the RPMs during pre-install as the sub make doesn't have LATEST_LINK, FALLBACK_ELF_MIB or RPMFLAGS set correctly (which in this case leads to the glibc-common RPM failing to execute its post-install scripts, which it wouldn't try to do if --noscripts was set). One possible solution would be to only use ARCH to set these flags and then set a variable named LINUX_ARCH that could be used in the names of the RPM files, etc. E.g. the above would become: .if (${ARCH} == "amd64") LATEST_LINK:= ${LATEST_LINK:C/linux/linux32/} TRUE_ARCH= i386 FALLBACK_ELF_MIB= kern.elf32.fallback_brand RPMFLAGS+= --noscripts .else TRUE_ARCH= ${ARCH} FALLBACK_ELF_MIB= kern.fallback_elf_brand .endif and all the other occurences of ${ARCH} would become ${TRUE_ARCH}. Comments? -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org
*sigh* s/TRUE_ARCH/LINUX_ARCH/g in that last bit. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org
Greg Lewis <glewis@eyesbeyond.com> wrote: > One possible solution would be to only use ARCH to set these flags and > then set a variable named LINUX_ARCH that could be used in the names > of the RPM files, etc. E.g. the above would become: [changes] > and all the other occurences of ${ARCH} would become ${TRUE_ARCH}. I don't have an amd64 machine to test this. And I haven't looked at the ARCH issues, since David seems to have work in this area. I like to incorporate at least John's patch into my linux-mega-patch. If your proposal is orthogonal to David's work I can integrate it into my mega patch (which is supposed to get a test run on the ports build cluster) too. I assume it works for you. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Windle shook his head sadly. Five exclamation marks, the sure sign of an insane mind. (Reaper Man)
On Wed, Apr 27, 2005 at 12:19:02PM +0200, Alexander Leidinger wrote: > Greg Lewis <glewis@eyesbeyond.com> wrote: > > >One possible solution would be to only use ARCH to set these flags and > >then set a variable named LINUX_ARCH that could be used in the names > >of the RPM files, etc. E.g. the above would become: > [changes] > >and all the other occurences of ${ARCH} would become ${TRUE_ARCH}. > > I don't have an amd64 machine to test this. And I haven't looked at the ARCH > issues, since David seems to have work in this area. > > I like to incorporate at least John's patch into my linux-mega-patch. I'd really like to see: -pre-install: +pre-su-install: committed right away. I don't see a need to delay that fix. > If your proposal is orthogonal to David's work I can integrate it into > my mega patch (which is supposed to get a test run on the ports build > cluster) too. I'd really like to hold off on the rest of this patch until /usr/ports is totally unfrozen and we can do some ARCH clean ups that is needed. Then we can have a good base to investigate issues from. -- -- David (obrien@FreeBSD.org)
David O'Brien <obrien@FreeBSD.org> wrote: > On Wed, Apr 27, 2005 at 12:19:02PM +0200, Alexander Leidinger wrote: >> I like to incorporate at least John's patch into my linux-mega-patch. > > I'd really like to see: > > -pre-install: > +pre-su-install: > > committed right away. I don't see a need to delay that fix. I have some other changes to linux_base-8 in my mega-patch too. Some of those don't need a delay too, but since the "bugs" are there very long, it doesn't hurt to wait until portmgr is able to test the complete patch. Since the above patch doesn't fix the complete issue (at least not on amd64), and since nobody stepped up to commit it yet, I offered to include the fix in my patchset. I don't mind if you (or someone else) commit the above patch now. >> If your proposal is orthogonal to David's work I can integrate it into >> my mega patch (which is supposed to get a test run on the ports build >> cluster) too. > > I'd really like to hold off on the rest of this patch until /usr/ports is > totally unfrozen and we can do some ARCH clean ups that is needed. Then > we can have a good base to investigate issues from. Agreed. While discussing this: Since your ARCH cleanup touches alot of ports and is a candidate for testing on the cluster, shouldn't we merge our patches and just let portmgr test the entire patchset? This may reduce the amount of conflict resolution work needed in case one patch hits the tree while the other is between two test runs. I will sync my patchset at the weekend (friday in the evening or saturday/sunday in the morning). Feel free to send a corresponding diff for integration to me. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Knowledge is power. -- Francis Bacon
State Changed From-To: open->closed Should be fixed, everything is handled in do-install: these days.