Package Building in the Large

[Jason C. Wells]

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