Date: Thu, 22 Nov 2007 10:16:53 -0800 From: Doug Barton <dougb@FreeBSD.org> To: "Jason C. Wells" <jcw@highperformance.net> Cc: freebsd-ports@FreeBSD.org Subject: Re: Package Building in the Large Message-ID: <4745C795.5020101@FreeBSD.org> In-Reply-To: <47459C80.8000206@highperformance.net> References: <474262D5.3010603@highperformance.net> <alpine.BSF.0.99999.0711220037270.982@qbhto.arg> <47459C80.8000206@highperformance.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason C. Wells wrote:
> Doug Barton wrote:
>> On Mon, 19 Nov 2007, Jason C. Wells wrote:
>>
>>> What I am trying to do is to build 30 or so packages including the
>>> big ones like X, kde, gnome, plus all of their dependencies on a
>>> build host and then use pkg_add on various machines. I have had a
>>> variety of difficulties with all of the methods I have used thus far
>>> (portmaster, portupgrade, homegrown).
>>
>> What problems did you have with portmaster? Did the backup package
>> creation fail in some way?
>>
> Not all dependencies had a package built for them. For my list of 31
> ports that I actually desired to build there was a dependency list (make
> all-depends-list) of 758 ports. Of those 758 ports there were 427
> packages built.
That's disturbing, but I think I know why it happened, see below.
> 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 seems that portmaster is intended to be run on the host where the
> existing ports are currently installed and where the new ports will be
> eventually installed.
That is its primary purpose, yes.
> 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.
> Not all hosts run the same set of packages.
That shouldn't matter as long as different hosts aren't running
different versions of the same package.
> Perhaps I misunderstand the -g and -b switches. I don't want backup
> packages of old ports.
That's what -b does.
> I do want packages for all new ports that are built during a run.
That is what -g does.
> 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. The OPTIONS are there for a reason,
and when they are changed it can (and often does) change the
dependency tree. Also, since the OPTIONS framework has been fixed, if
the options in the Makefile haven't changed, portmaster won't prompt
you to reset options you've already set, so you get all the benefits
with very little of the cost. This flag should be used primarily when
you have to restart a build of a given port because the first build
failed.
If you're starting with a clean /usr/local then the -t option is not
needed, but it probably won't hurt anything. You do misunderstand what
the -p switch is for, and specifying the list of ports in the manner
you did is probably not the best way to go about it. I'm also unsure
what /usr/ports/ports is supposed to be, unless that's a local path
issue.
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
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.
> I think portmaster worked as expected.
If you invoked it the way you described, I'm pretty sure it didn't do
what you expected it to do. :)
> It just didn't do what I
> desired. Hence my original question to the list.
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.
> The tinderbox port looks like the right functionality. It also looks
> heavyweight requiring apache+mysql. I am trying to avoid dealing with
> extra databases. I spent a lot of time messing around with the database
> under portupgrade. I have come to the opinion (like the idea behind
> portmaster) that there are already databases built into the port
> system. I'd rather just use them in place.
>
> I would also like the portmanagers to know that I think they do a
> bang-up job. I just have my ultra narrow fussy roll your own way of
> doing things. I am looking for the right method _for me_. All of the
> above is no criticism.
I certainly don't take it that way, and I appreciate both your kind
words and the amount of thought that you put into this. Best of luck
to you.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4745C795.5020101>