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
> decision.)
>
> 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.)

"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?)

Russell

> 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.
>
> mcl
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>


More information about the freebsd-ports mailing list