Package Building in the Large

[Chuck Robey]

Doug Barton wrote:
> 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'm more disturbed that this piece of news isn't common knowledge. 
Those numbers actually understate the problem.  Just one commonly 
required port, one of the browsers like Firefox, alone brings in over 
300 dependencies.  At least in my own opinion, the largest part of that 
dependency list is VERY weakly required, mainly a matter of a porter 
saying to himself "I have that port, I like it a lot, everybody should 
have it" and not "this port won't run without that port"

That's my own main motivation behind all that work I'm doing aboout 
making a ports keyword list, so as to better control the growth of 
dependency lists.  It's no problem at all to show ludicrous examples of 
overly agressive dependency lists taking the choices of what ports to 
add out of the hands of the users.

As soon as I get the keyword list written (asnd who knows, maybe 
accepted?), then I intend to push what I see as the second part of this, 
a tool that looks at what ports are installed, the state of your keyword 
lists, and a user's personal interests, and make suggestions of what 
ports a user might find interesting.  Sort of a ports-advertiser.  This 
would take the place of overly agressive dependency lists, but not by 
removing the user from the process, but instead by making that user's 
selection job easier to make.  Such a tool could have a link to a ports 
installer, even, so as to further ease things, but not to remove the 
choice from the user, as it's moving towards today.