BIND REPLACE_BASE option
Russell L. Carter
rcarter at pinyon.org
Mon Jan 12 04:50:56 UTC 2015
On 01/11/15 21:01, Mark Linimon wrote:
> 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.)
This is the problem. There is /usr/ports/UPDATING, but those of us who
sensibly use cron & poudriere to update our [ports & pkg] tree never
see the contents of /usr/ports/UPDATING. Even with systemd cancer
spreading all through debian I have only had one system fail, using
apt-get dist-upgrade. Because notice is given in the "upgrade" process
that incompatible changes are being made.
The discussion of recent pinentry related stuff comes to mind. Since I
have already ranted at length on why this is a show stopper,
on basic human security grounds, I'll stop here. (Nope, as you can see,
I'm not using anything that pinentry was intended to facilitate. How
could I, on FreeBSD?)
> 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.
> freebsd-ports at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports