Re: Using PKGSRC to install to non-standard LOCALBASE
Justin C Sherrill [EMAIL PROTECTED] writes: It may be possible to do something in a jail or with chroot where you build a new pkgsrc location with a bootstrap, install to that location, package up that install, and then use it with your normal pkgsrc install. This appears to be a working strategy when coupled with null mounts. It was kind of fun to do too. ;) Thanks. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own Obviously, the obvious is not obvious --The Unknown Drummer
Re: Using PKGSRC to install to non-standard LOCALBASE
On Sun, 24 Jun 2007, Dave Hayes wrote: If I wanted to build Apache, for example, out of pkgsrc but I wanted it to be installed to a different prefix than LOCALBASE, how would I do that? There's enough warnings about using different values for LOCALBASE that I'd thought I'd check with the more experienced people out there. The pkgviews support is supposed to be able to do that also. I have used it before, but last time I tried it didn't work for me anymore. (I have read postings from others indicating it does work though.) Jeremy C. Reed
Re: Using PKGSRC to install to non-standard LOCALBASE
reed [EMAIL PROTECTED] writes: The pkgviews support is supposed to be able to do that also. I have used it before, but last time I tried it didn't work for me anymore. (I have read postings from others indicating it does work though.) Thanks for the pointer. I was unable to immediately determine how to get it to use a different LOCALBASE, but I have to say it's a fine idea in theory. I haven't put the requisite time in to consider whether the infrastructure work Matt Dillon on his new filesystem (i.e. the different views of a directory) might be a better solution to the problem that pkgviews is solving, but I'd certainly love to hear what more experienced minds have to say on this topic. In the meantime, I guess I'll be using the chrooted alternate pkgsrc build environment. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own It is a dragon, destroyer of all, cried the ants. Then a cat caught the lizard.
Re: Using PKGSRC to install to non-standard LOCALBASE
On Sun, Jun 24, 2007 at 09:07:07AM -0700, Dave Hayes wrote: If I wanted to build Apache, for example, out of pkgsrc but I wanted it to be installed to a different prefix than LOCALBASE, how would I do that? The recommented way is to bootstrap to the new prefix and use the bmake from that. You can with some care alter the LOCALBASE variable together with PKG_DBDIR to get a similiar effect, but IMO it is more likely to hit problems like which combination am I currently running with. Joerg
Using PKGSRC to install to non-standard LOCALBASE
If I wanted to build Apache, for example, out of pkgsrc but I wanted it to be installed to a different prefix than LOCALBASE, how would I do that? There's enough warnings about using different values for LOCALBASE that I'd thought I'd check with the more experienced people out there. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own If it works...use it. If it doesn't, find out why and use THAT.
Re: Using PKGSRC to install to non-standard LOCALBASE
On Sun, June 24, 2007 12:07 pm, Dave Hayes wrote: If I wanted to build Apache, for example, out of pkgsrc but I wanted it to be installed to a different prefix than LOCALBASE, how would I do that? There's enough warnings about using different values for LOCALBASE that I'd thought I'd check with the more experienced people out there. My impression was that pkgsrc changes its base location monolithically; e.g. all packages to the same spot, which is /usr/pkg/ by default. It may be possible to do something in a jail or with chroot where you build a new pkgsrc location with a bootstrap, install to that location, package up that install, and then use it with your normal pkgsrc install. Or I could be overcomplicating it. [EMAIL PROTECTED] may also have answers.