Dependencies: base vs. ports (Was: Re: ports/187468)

Kevin Oberman rkoberman at
Wed Mar 12 19:17:31 UTC 2014

On Wed, Mar 12, 2014 at 8:16 AM, Bryan Drewery <bdrewery at> wrote:

> On 2014-03-12 09:36, Alexey Dokuchaev wrote:
>> On Wed, Mar 12, 2014 at 07:01:20AM -0500, Bryan Drewery wrote:
>>> > On Mar 11, 2014, at 23:48, Alexey Dokuchaev <danfe at> wrote:
>>> >> On Tue, Mar 11, 2014 at 07:50:37PM -0500, Bryan Drewery wrote:
>>> >> This goes against our plans to have all ports depend only on ports. I
>>> >> admit this has not been communicated well. libexecinfo should probably
>>> >> be moved to /usr/lib/private on head to prevent ports from using it.
>>> >
>>> > [ Taking this to ports@ as it deems important on its own ]
>>> >
>>> > What's wrong with depending on system libraries?  OSVERSION check does
>>> > indeed make it a bit hackish; I would use
>>> !exists(/usr/include/execinfo.h)
>>> > instead, but the change itself is fine, I also do so (cf.
>>> biology/ugene).
>>> You conveniently trimmed out a lot of context here. This thread was not
>>> 'Re: ports/187468' on this list.
>> "Taking this to ports@" implies that this thread did not originate on
>> ports at .
>> I could've simply omit reference to PR altogether; what context from the
>> PR
>> changes the meaning of "plans to have all ports depend only on ports"?
>>  IMHO
>> leaving a PR number is enough for anyone who's interested to find the
>> origin
>> of the discussion, but I'm not that worried about PR rather than the
>> problem
>> with base dependencies.
>>  Problems with depending on base: [...]
>> Thanks for an in-depth answer; most (if not all) of this makes sense.
>>  Sorry
>> if it was discussed earlier and my question caused you quite a deal of
>> extra
>> typing; all I can say in my defence that I really appreciated it.
>> ./danfe
> No, I do appreciate it. We need to communicate more. Bapt and I had
> discussed
> this with Des briefly and had pretty much taken on this task privately.
> These
> things do need to be discussed in public more.

Thanks, danfe, for bringing this to everyone's attention.

Too many changes that have had a significant impact on users have been
discussed in near (if unintended) privacy and then suddenly were
implemented. Most of these changes has been for the better and I'd not want
to see them rolled back, but on a couple of cases a bit more notice would
have been nice. (The big exception was pulling BIND from the base system
with fairly short notice and a major downgrade in the security of the
default port installation vs. the old ports or the base install. All on the
basis of a mistaken belief of the time that BIND9 would be supported. Had
any of us who worked closely with BIND known of this, the mistake could
have been rectified and a lot of work as well as confusion avoided. OTOH, I
am happy to see BIND out of the base OS.)

This one is really, really big. It is a fairly fundamental change in how
ports does things. It will mean more installed ports and may be a bit of a
double-edged sword for maintainability. I like the concept and I suspect
that, once I have given it enough though, I will agree that it's a good
idea. I'm just happy that a lot of people a lot smarter than I am will be
looking at it, too, for potential issues. And it should not be a sudden
implementation as it should be done one facility at a time.

And, just to be clear, I do NOT believe that those in portsmgr were
deliberately trying to hide things. (Conspiracy theorists will, of course,
disagree.) It's just that it is easy to forget how limited some audiences
are compared to the number of people who can do valid evaluation of a major
proposal and make useful suggestions.
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at

More information about the freebsd-ports mailing list