On Mon, Jan 07, 2013 at 03:09:05PM +0000, Vernon Schryver wrote:
> That makes no sense to me, because RPZ has been present in ISC's BIND9
> since 2010 and BIND 9.8.0. Unless you've been removing the RPZ code
> from the FreeBSD bind98-* and bind99-* ports and packages, you've long
> been shipping RPZ.
Correct, we have shipped stock RPZ since it appeared in Bind.
>
> On the other hand, obvious Google searches with "site:freebsd.org" and
> on http://www.freebsd.org/cgi/ports.cgi find no signs that FreeBSD is
> doing anything with the BIND9 RRL patch.
I've had several request to add it as an experimental option (default
off), so I added it last week:
http://svnweb.freebsd.org/ports?view=revision&revision=309924
>
> Perhaps you did not mean to talk about making RPZ an option in the
> FreeBSD BIND port or package but to make the one or the other version
> of faster RPZ code an option. That would be a mistake, because neither
> new version of RPZ nor RRL is ready for release. When (and if ever)
> they are ready, they will appear in official BIND 9 releases or perhaps
> somehow in the ISC BIND9 contrib directory.
You seem to forget there is a real world out there. Many people,
including at the TLD level, are running with this patch out of sheer
necessity, even if it is still considered experimental. For those
people, having at least the possibility to turn it on via the packaging
system of choice makes their lifes much easier with respect to their
internal patch management, puppet, etc.
>
>
> > Would it be possible to
> > have those two split into two different patch sets?
>
> No.
Ok.
>
> If it were easy to make them independent patches, then it would have
> been done. I maintain 3 separate git branches. Unfortunately for me
> and my hatred of merging and merge-errors, they change some of the
> same source and so cannot easily be independent. In theory, I could
> release 6 more patches (rrl, rpz, and rpz2 for two most current ISC
> BIND9 releases), but that would confuse me too much and bring too many
> bug reports from others trying build their own rpz*+rrl versions.
>
>
> Please excuse my tone. I have hard feelings toward repacking second
> guessers in general and particularly some in the Linux communities for
> their "improvements" (spelled m-i-n-o-r--d-a-m-a-g-e) to DCC (see
> https://www.google.com/search?q=dcc+spam ) and more important, for
> their refusal to ship stop shipping ancient code with my old, bad bugs.
> For the last 7 years they have been responsible for most of the entries
> on the blacklist used by the public DCC servers to protect themselves
> from deranged clients. Those who want to fork source ought to have
> the courage and honesty to say that's what they're doing and to accept
> responsibility for the consequences of their efforts instead of...well,
> never mind.
>
Excuse my English, but I do resent your tone and especially being
treated as yet another random Linux distribution out there. Look at the
code before you make assumptions. The patch is marked as experimental,
off by default, and if turned on, applied verbatim. I have no intention
on making any "improvements" as this will only lead to more work for me
and, as you point out, may actually break the original authors
intention. As I already said, the option was added, even if the patch
is considered experimental and not ready for production, because people
need it and are running it in production.
Now, my question actually doesn't have anything to do with (re)packaging
at all. Anyone who wants to use RRL and RPZ, but want to keep stock
RPZ, or the other way around, will no longer be able to do so. It may
be that there are no or very few people that do so and that you don't
care about them, which is absolutely fine. It's your patch and your
party. Just remember there are real users out there.
Erwin
--
Erwin Lansing (o_ _o) http://droso.dk
\\\_\ /_///
erwin at lansing.dk <____) (____>