Package Building in the Large
chuckr at chuckr.org
Sun Nov 25 18:43:59 PST 2007
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.
More information about the freebsd-ports