Limitations of Ports System

Danny Pansters danny at
Thu Dec 13 18:13:33 PST 2007

On Thursday 13 December 2007 19:17:34 Warren Block wrote:
> On Thu, 13 Dec 2007, Steven Kreuzer wrote:
> > This thread was called "results of ports re-engineering survey" but I
> > figured I would start a new thread.
> Rightly so.
> > On Dec 12, 2007, at 6:45 AM, Ade Lovett wrote:
> >> We *know* it can be done better.  We *know* the scaling limits of the
> >> current system, and most of us are completely amazed it even still
> >> works.
> >>
> >> If y'all want to make a difference, concepts and ideas we have plenty
> >> of. Code talks.
> >
> > Out of curiosity, are any of these shortcomings documented anywhere? I
> > have been using ports on my home machine for a long time and I've never
> > had any problems with it. I assume the issues come into play when you
> > work with multiple systems you are trying to keep in sync, etc.
> >
> > I would be interested in reading about some of the limitations people
> > have run into when using ports.
> Notable with the new modular Xorg is the speed of changes
> (install/deinstall/clean) when there are a lot of ports installed.
> Before modular xorg, 400 ports installed was a lot.  700 now is not
> surprising.
> Some profiling looking for areas which could benefit from speed
> optimization would be useful.  That may have already been done but not
> publicized.

Well, I can tell you what I think:

If we don't want thousands of global knobs, then it's either splitting up in 
almost atomic micro ports which inflates the number of ports or using port 
OPTIONS... BUT... we currently have no standard mechanism to actually use 
another port's OPTIONS in a somewhat generic way.

It's all about where and how you want to have your granularity (sp?) I think.

In the longer run, being able to specify a port's options when specifying 
DEPENDS would probably be a very useful and not very invasive change for the 
better (or maybe if that's simpler -- doubt it -- some sort of OPT_DEPENDS).

If someone wants to work specifically on addressing - to put it bluntly - 
the "debianizing-ports-versus-optionifying-properly" issue I'm interested in 
chipping in or if needed leading such an effort. The scope should be only 
that and it must be backwards compatible.

Some food for thought maybe,


More information about the freebsd-ports mailing list