BIND REPLACE_BASE option
linimon at lonesome.com
Mon Jan 12 04:01:31 UTC 2015
On Sun, Jan 11, 2015 at 03:54:39PM -0800, Roger Marquis wrote:
> "time for it to go", by whose definition? Good code doesn't have a
> fixed lifespan and the claimed rationale doesn't constitute a good
> business case.
It was believed to be a bad design pattern to let ports modify anything
in base. There had been a few exceptions that crept in over the years,
for one reason or another. Apparently 10.0 seemed like the appropriate
time to get rid of the bad pattern. (Note: I was not involved in the
We've been essentially rewriting the entire ports infrastructure in-place
for the past 6 or 7 years. IMVHO this was entirely necessary: the old
pkg_* tools were buggy, underdocumented, and no longer suited to the task
of keeping up with over 20,000 ports. Along the way we've had to throw
out a lot of rotten code both in the infrastructure and various ports --
*and* keep the absolute majority of ports working in the meantime. This
was no mean feat.
> Sometimes you really have to wonder whether these feature deprecations
> are due less to resource shortages than to special interests outside of
> FreeBSD's user-base.
They are mostly due to the idea of not shipping things that do not work
consistently, and in the way one "might expect". On rare occasion, yes,
that will mean breaking POLA.
(Also note I'm not defending the way this change was or was not documented.)
As for "special interests", this is specious. AFAIK the companies that
embed FreeBSD into their products are primarily interested in the kernel,
the networking stack, the file systems, and so on. I do not know of any
such company that even _uses_ FreeBSD ports.
Thus, they could have no influence on the outcome.
tl;dr: the FreeBSD ports community is pretty well self-contained.
More information about the freebsd-ports