Bug 256450 - dns/djbdns: Deprecate and set expiration date to 2021-09-06
Summary: dns/djbdns: Deprecate and set expiration date to 2021-09-06
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Robert Clausecker
URL: https://bugs.freebsd.org/bugzilla/sho...
Keywords:
Depends on:
Blocks: 246317
  Show dependency treegraph
 
Reported: 2021-06-06 18:24 UTC by Daniel Engberg
Modified: 2023-12-17 12:55 UTC (History)
8 users (show)

See Also:
bugzilla: maintainer-feedback? (lx)


Attachments
Patch for djbdns (1.29 KB, patch)
2021-06-06 18:24 UTC, Daniel Engberg
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Engberg freebsd_committer freebsd_triage 2021-06-06 18:24:03 UTC
Created attachment 225604 [details]
Patch for djbdns

This is now considered unmaintained by upstream and several have removed it from their package/doesn't offer it (CentOS, Debian (removed from stable), Fedora, OpenBSD, OpenSUSE, Ubuntu to mention a few).

For more technical insight https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796118 etc
Comment 1 David Thiel freebsd_committer freebsd_triage 2021-06-06 18:40:21 UTC
While I agree that dnscache is somewhat obsolete, tinydns is still solid and widely used, and removing it would likely cause more frustration than good. Splitting it into separate ports would be better, but that would break patches (like the IPv6 one). I'm open to other suggestions, but I personally am not in favor of removal.
Comment 2 Daniel Engberg freebsd_committer freebsd_triage 2021-06-06 19:24:38 UTC
Hi,

Perhaps another solution would be migrating to https://github.com/mbhangui/tinydnssec (another fork seems to be http://pjp.dgplug.org/ndjbdns/ but dead as far as I can tell) which at least is (somewhat?) maintained?

I do understand your concern however I also think that we need to consider the fact we should/need to move forward at some point and it's imho better sooner than later. 3 months might be a short in that regard, perhaps 6 months would be better depending on which route we'll take.
Comment 3 David Thiel freebsd_committer freebsd_triage 2021-06-06 20:22:51 UTC
Of those two, I lean toward ndjbdns — it does switch to .conf files which would unfortunately require manual migration, and it is GPL, but at least it doesn't introduce a new dependency on another libc replacement. There's an updated fork of it here we could consider:

    https://github.com/samboy/ndjbdns

Another option could be going with the version included in this, which does at least consider FreeBSD:

    http://jdebp.uk./Softwares/djbwares/

Personally, the main thing keeping me on tinydns is tinydns-data. If there were anything that supported that format or spit out the abominable BIND format zone files from it, I'd be more inclined to abandon djbdns altogether.

Any thoughts on those?
Comment 4 Daniel Engberg freebsd_committer freebsd_triage 2021-06-06 21:00:25 UTC
Hmm.. the samboy fork seems like a good tradeoff I we want to keep it?

I found this https://gist.github.com/gmr/10434366 but I haven't tested it myself and since it's from 2014 I would imagine that you need python 2.x
Comment 5 Leo Vandewoestijne 2021-06-17 12:44:37 UTC
(In reply to Daniel Engberg from comment #0)
> For more technical insight https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796118 etc
>
From that pointer I don't understand why a 6 y/o RC bug in Debian (Linux) today became the argument to remove it in FreeBSD, especially since it works i.c.w. daemontools. I fail to see the problem / did I miss something?

Is it truly unmaintained?
And even if, is that truly a problem?
Looking ahead into the future, in the hypothetical case of very-long awaited truly critical vulnerability in the tinydns daemon part, ain't the software then still useful for the tinydns-data part? (which creates a datatree which can even be served by PowerDNS).
Also tools like dnsdist -which many serious operators have in place- may still neutralize such hypothetical problem (or challenge).
Comment 6 Daniel Engberg freebsd_committer freebsd_triage 2021-06-17 22:29:11 UTC
Hi Leo,

I suggest that you read all comments not just the top one, I think it'll give you a better view on the issue. It's already removed in many major distros https://repology.org/project/djbdns/versions and one could argue that it's not advisable to "promote"/have buggy/broken/abandoned software available when there are good alternatives. I'm not saying that pushing people out of their habbits is something we should promote but sometimes you may need a little push to move forward. If we can provide a solution with little to no friction that's even better.

Best regards,
Daniel
Comment 7 Leo Vandewoestijne 2021-06-21 14:33:03 UTC
(In reply to Daniel Engberg from comment #6)

> I suggest that you read all comments not just the top one
>
Implicates like if I didn't.
If your point was clear, I didn't had to ask for clarification.
Meanwhile: you avoid answering, so the questions remain.


> I think it'll give you a better view on the issue. It's already removed in many major distros https://repology.org/project/djbdns/versions
>
Supermarket K removes product X from their assortment because it doesn't fit perfectly well in their new shelves, does that immediately indicates product X is bad or harmful, such that supermarkt Z should drop it also?


> could argue that it's not advisable to "promote"/have buggy/broken/abandoned software available when there are good alternatives.
>
Buggy? Broken?
In my country such defaming is prosecutable both under civil and criminal law.

Abandoned?
After 2 decades of no updates you could also state it's pretty good in not being vulnerable, in no compare to any other DNS daemon.

Good alternatives?
For your common usecase, sure. But not for all of mine, and others.


> sometimes you may need a little push to move forward.
>
Stop pushing me please. Have dialog before dictating.
What makes you think I only need what you deem forward and don't need nothing else?


> If we can provide a solution with little to no friction that's even better.
>
Name at least 2 (two) options to synchronize 300 million RR's all at once, with checksum, twice a minute, without inefficient useless XFR overhead, nor depending on an extra backend, and can reload all that data in a split second.
(and please not a fork of something you're now removing the forks handle from).
IF you can "provide a solution that's even better" then I'm all ears, even more than I already am.

The last time when I talked with Facebook DNS engineers also they were using it the same way, distributing all their internal DNS to all their DC's.


I'm sorry to say, but I find the lack of any truly convincing argument and additional false arguments unfair and uncanny. And so I still fail to comprehend what is the real problem here.
Comment 8 Felix Hanley 2022-01-28 05:42:59 UTC
Just another "vote" to keep in the tree. It continues to work almost flawlessly for me. I love the way it has not changed for so many years.

If anything, expand the patch options for it so that it becomes *more* useful.
Comment 9 Rene Ladan freebsd_committer freebsd_triage 2022-04-26 09:44:03 UTC
Maintainer reset.
Comment 10 Rene Ladan freebsd_committer freebsd_triage 2022-04-26 09:44:10 UTC
Maintainer reset.
Comment 11 commit-hook freebsd_committer freebsd_triage 2023-02-27 20:45:48 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=09b46a68171312152af074f5bf8aa2336a87e797

commit 09b46a68171312152af074f5bf8aa2336a87e797
Author:     Daniel Engberg <diizzy@FreeBSD.org>
AuthorDate: 2023-02-27 20:40:02 +0000
Commit:     Daniel Engberg <diizzy@FreeBSD.org>
CommitDate: 2023-02-27 20:45:18 +0000

    dns/djbdns-tools: Deprecate and set expiration date to 2023-06-30

    Project hasn't been centrally managed since last release in 2001 and
    there are various third party patches to keep it somewhat relevant with
    todays standards. Port has also been unmaintained since last
    maintainer stepped down several months ago.

    PR:             256450

 dns/djbdns-tools/Makefile | 3 +++
 1 file changed, 3 insertions(+)
Comment 12 commit-hook freebsd_committer freebsd_triage 2023-02-27 20:45:50 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=1bece199848e019caee2104727d30353177ed978

commit 1bece199848e019caee2104727d30353177ed978
Author:     Daniel Engberg <diizzy@FreeBSD.org>
AuthorDate: 2023-02-27 20:32:43 +0000
Commit:     Daniel Engberg <diizzy@FreeBSD.org>
CommitDate: 2023-02-27 20:45:18 +0000

    dns/djbdns: Deprecate and set expiration date to 2023-06-30

    Project hasn't been centrally managed since last release in 2001 and
    there are various third party patches to keep it somewhat relevant with
    todays standards. Port has also been unmaintained since last
    maintainer stepped down several months ago.

    PR:             256450

 dns/djbdns/Makefile | 3 +++
 1 file changed, 3 insertions(+)
Comment 13 Daniel Engberg freebsd_committer freebsd_triage 2023-02-27 20:56:12 UTC
Port and related ones are now deprecated with a relevant epiration date.
Comment 14 pprocacci 2023-08-16 18:36:30 UTC
I've since discovered this has been removed.
One more nail in the FreeBSD coffin.

There's a reason why I've used FreeBSD since the early days and that's because the ports tree mainly.  I could easily use what *I* wanted -- djbdns being one of them.

The arguments presented above are hogwash.  It's software that works and needs no updating and contrary to what some believe isn't buggy -- it just works(tm).

Leo's comments are extremely valid and it'd be a waste of breadth to reiterate them.

Instead, I'll state something different which is:

- The software ISN'T DEPRECATED.  Contrary to what the port maintainers think, it's still in use all over the world.

- The software is extremely useful.

- It doesn't need updating.  Has anyone tried actually downloading the source as is and running on their system?  I have, and you know what?  It works perfectly fine.

But biggest of all:

- Having this port in the ports tree hurts absolutely no one.  Seriously, if the software doesn't get updated because it doesn't have too, then there's no need for port maintenance.  

Imbecile's.

/rant over
Comment 15 Leo Vandewoestijne 2023-08-23 15:16:15 UTC
I'm not happy being named by name i.c.w. such hostile words.

Please bare in mind such addressing is harmfull to the motivation of volunteers, who I believe have prosper intentions, and contribute their valuable time, and therefor deserve more respect - even while having different opinions.
Comment 16 Daniel Engberg freebsd_committer freebsd_triage 2023-08-25 18:32:28 UTC
(In reply to Leo Vandewoestijne from comment #15)
We all do mistakes, I don't see an issue as long as you learn from them. If there's disagreement I welcome a discussion as long as it's within CoC.

Best regards,
Daniel
Comment 17 BobT 2023-08-31 17:32:35 UTC
I went and created an account just for this. I 2023. The djbdns is just perfect software for what it does, no need to "update" it. So what if it is 20 years old.

There are a lot of real bugs in some other packaged that are not being fixed for years, and this is being remove because it does not have any bugs needed to be fixed? We are really living in idiocracy. https://www.imdb.com/title/tt0387808/


"It's software that works and needs no updating and contrary to what some believe isn't buggy -- it just works(tm)."

It caused a major pain for me to install it from source and compile and then send it over to pfsense ... all that work... sad ... very sad...
Comment 18 Robert Clausecker freebsd_committer freebsd_triage 2023-11-10 20:39:09 UTC
Due to popular demand, I'll go ahead and see if I can restore the port.
Comment 19 Daniel Engberg freebsd_committer freebsd_triage 2023-11-11 08:00:00 UTC
Unless there's going to be a maintained "community/open" repo (and effort) there's no valid reason for doing so. It doesn't follow todays practices, you need to patch it heavily and these patches are also incompatible with each other. All attempts (to my knowledge) of creating a unified repo been abandoned several years ago. There have been no offers made for maintaining a repo or even the port itself. This was also resolved months ago by removing it. The ports tree is also not the correct way of maintaining a project, a separate repo should be used and it should be a genuine attempt of doing so to be even considered.
Comment 20 Daniel Engberg freebsd_committer freebsd_triage 2023-12-16 15:49:07 UTC
Closing this as there have been no progress since removal almost 6 months ago.
Comment 21 Robert Clausecker freebsd_committer freebsd_triage 2023-12-17 12:41:06 UTC
This is still planned, I just didn't have the time to work on it yet.
Comment 22 Robert Clausecker freebsd_committer freebsd_triage 2023-12-17 12:55:45 UTC
By request of diizzy@, efforts to restore the port are now being tracked in bug #275803.  Please subscribe to that bug if you wish to be kept up to date.