Date: Thu, 22 Nov 2007 11:13:43 -0800 From: "Jason C. Wells" <jcw@highperformance.net> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-ports@FreeBSD.org Subject: Re: Package Building in the Large Message-ID: <4745D4E7.6090907@highperformance.net> In-Reply-To: <4745C795.5020101@FreeBSD.org> References: <474262D5.3010603@highperformance.net> <alpine.BSF.0.99999.0711220037270.982@qbhto.arg> <47459C80.8000206@highperformance.net> <4745C795.5020101@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Most of the message below is just rounding out the discussion. There is one significant question on recursion though. Doug Barton wrote: >> I also ended up with shared a library version problem >> in at least one port (grip) in spite of having started my build with a >> completely vacant /usr/local. > > That sounds like a problem with the ports. I can't think of any way > that portmaster would cause that. It might be due to a non-clean /usr/local on the target install host. It was a foo.so.3 is required but foo.so.2 is installed sort of error. I haven't dealt with the installation step in a meaningful way yet. Don't worry about responding to this bit. >> It looks to have good port upgrading abilities, >> but that is not what I am after. What I am trying to do is operate a >> build host and distribute packages from there. > > That is not its primary purpose, but assuming that your systems are > similarly configured, and running an OS version that's fairly close in > age, there is no reason that portmaster shouldn't be able to at least > create the packages that you can then distribute manually. All my systems run a -release and all ports are tagged with the same -release. (With a few odd cases when security issues demand.) A few years ago I decided to stop tracking -stable and just run pure releases. I now spend less time administering my five or so systems. By what you claim, portmaster should suffice. >> I used 'portmaster -GgDt -p /usr/ports/ports $pmarg' for my run >> where $pmarg was the list of 31 ports. > > That's definitely not going to work, for several reasons. The -G > switch should only be used _after_ you've already run portmaster > without it for a given port build. I had manually run 'make config-recursive' previously. I'll do as advised at any rate. > I'm also unsure > what /usr/ports/ports is supposed to be, unless that's a local path > issue. It's a local hierarchy issue. I pushed the ports tree up one level and therein lie 6.2, -current, and the soon to be 7.0 trees. /usr/ports/ports is a link to the tree I was working on in which is /usr/ports/ports-current. Once the FreeBSD portmanager pulls the trigger I will be dealing with 7.0 exclusively. > Assuming that your list of ports is relative to the /usr/ports > directory (e.g., 'archivers/unzip astro/planets', etc.), what I would > do is: > for dir in $pmarg; do > portmaster -BgD -p /usr/ports/$dir > done Aha! I had an error (don't recall exactly) without using -p where the complaint had something to do with not finding something in /usr/ports. So I fired up the manual and then found the -p switch and assumed that was how I told portmaster where the ports tree was stored. I think this is the ticket. I don't have my manpages handy right now but I'll take a closer look. But what about recursion? I held the notion the portmaster did magically delicious recursion and so I thought that providing the list of ports to a single invocation of portmaster would allow portmaster to sort the build order correctly. The code snippet you show would cause portmaster to _forget_ recursion information during each iteration of the loop. My concern was that some dependencies would be built more than once. That's dog slow. > Replace the literal "/usr/ports/" in that string with the actual > location of your ports tree if its different. You probably also want > to add the -v switch in there for the first few runs to familiarize > yourself with what's going on, and review the man page. > Please note, I am not saying that portmaster will definitely be the > right solution for you. However, I do think it's worth pointing out > that if used properly it should at least be able to do what it says it > can do. I'll give it another go. Later, Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4745D4E7.6090907>