Bug 23539
| Summary: | make installworld from nfs mounted /usr/src and /usr/obj requires write access | ||
|---|---|---|---|
| Product: | Base System | Reporter: | jonathan <jonathan> |
| Component: | misc | Assignee: | Marcel Moolenaar <marcel> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
jonathan
2000-12-14 06:20:03 UTC
Responsible Changed From-To: freebsd-bugs->marcel Marcel, as our Makefile.inc1 guru can you please have a look at this. Perl is a real PITA. Our current mentality WRT perl is that if it (cross-) builds, we're happy. Trying to have perl conform to our build process proved to be 1) impossible or 2) painful. The question we ask ourselves is: Do we want to take perl sources from the vendor branch (ie muck with /usr/src/contrib/perl5) or do we solve problems in our makefiles (ie muck with /usr/src/gnu/usr.bin/perl). What we probably need at this time is someone who is willing to put in the effort to get perl to conform to our standards in such a way that has the least impact on maintainability and upgradability and is willing to maintain it. I don't think we're going to see progress until that happens... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 I don't have any familiarity with the FreeBSD (or Perl) build structure, but I'd suggest moving the write-access portion of the perl build into make buildworld from installworld But what you're telling me is that perl's install target requires write access, and the solution is either to restructure Perl into the BSD make system, or write a hack in buildworld to modify the Perl makefile to avoid the failing rm command, or at least make its failure non-fatal? -Jon > -----Original Message----- > From: marcel@cup.hp.com [mailto:marcel@cup.hp.com] > Sent: Friday, December 15, 2000 11:48 AM > To: freebsd-gnats-submit@FreeBSD.org; jonathan@graehl.org > Subject: Re: misc/23539: make installworld from nfs mounted > /usr/src and > /usr/obj requires write access > > > Perl is a real PITA. Our current mentality WRT perl is that if it > (cross-) builds, we're happy. Trying to have perl conform to our build > process proved to be 1) impossible or 2) painful. > > The question we ask ourselves is: Do we want to take perl sources from > the vendor branch (ie muck with /usr/src/contrib/perl5) or do we solve > problems in our makefiles (ie muck with /usr/src/gnu/usr.bin/perl). > > What we probably need at this time is someone who is willing to put in > the effort to get perl to conform to our standards in such a way that > has the least impact on maintainability and upgradability and > is willing > to maintain it. I don't think we're going to see progress until that > happens... > > -- > Marcel Moolenaar > mail: marcel@cup.hp.com / marcel@FreeBSD.org > tel: (408) 447-4222 > Jonathan Graehl wrote: > > I don't have any familiarity with the FreeBSD (or Perl) build structure, > but I'd suggest moving the write-access portion of the perl build into > make buildworld from installworld If it only was that simply :-) > But what you're telling me is that perl's install target requires write > access, and the solution is either to restructure Perl into the BSD make > system, or write a hack in buildworld to modify the Perl makefile to > avoid the failing rm command, or at least make its failure non-fatal? Yes, something along those lines. I leave the PR open so that I someday (hopefully not in the too-distant future) muck with Perl. There's already an issue I have to solve with Perl. While there, I might as well fix this PR... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 State Changed From-To: open->closed This was fixed a while ago. Installs with a RO /usr/src and /usr/obj are possible for RELENG_4 and later versions. |
