Created attachment 226055 [details] ftp/wzdftpd: revive and fix -fno-common issue This revives ftp/wzdftpd and fixes build with -fno-common. The option OPENSSL is marked as BROKEN due to an OpenSSL related build problem. Option GNUTLS remains a viable alternative. Also expand the default options a bit more so the binary port has broader use. The old WWW is dead. Replaced with sourceforge site. I'm willing to take up maintainership for this unmaintained port.
Hi Robert, Is there specific functionality you need? In general I think we should refrain to import unmaintained software regarding further maintenance, security concerns and especially since it's already been removed from the tree especially if it can be replaced with something in tree. Best regards, Daniel
(In reply to Daniel Engberg from comment #1) Revival of the port was requested by a user on reddit: https://www.reddit.com/r/freebsd/comments/o7px9b/h310483/ If desired, I can ask the user in question to comment on his/her use case.
Please do Best regards, Daniel
Justification from /u/Catsssssssss on reddit: Of all the FTP servers I have tested and worked with, none can hold a candle to the versatility and capabilities of wzdftpd. Being able to manage all users, groups, permissions and other settings directly from the FTP client is ingenious. Additional to that, the user database can be hosted on a proper SQL server like postgres or mysql. It is quite simply far and beyond anything I have ever had the pleasure of using. There is minimal fiddling with config files once the server is installed as everything is handled via FTP SITE commands from the client. It is a crying shame that noone has picked up the project since the original developer stopped working on it. https://www.reddit.com/r/freebsd/comments/o7px9b/-/h33hxiw/
(In reply to Daniel Engberg from comment #3) So... any comments on the use case? Is this enough for revival?
(In reply to Robert Clausecker from comment #5) > Is this enough for revival? Sounds fair enough to me, I'll take it from here.
Hi, Sorry for the late reply! While there aren't any guidelines as far as I know regarding abdandonware I personally would lean more towards no as it hasn't been touched since 2007 and did get removed because no one submitted a fix within a reasonable timeframe. In addition to that ftp is slowly getting deprecated in general. I do realize that users of wzdftpd most likely aren't your average user but I guess the point comes though. We do have several other ftp servers that are maintained so instead of clinging into it until infinity most likely better to let it go. This is looking at it from a broader perspective in general nothing specifically regarding this port. One port may be fine but when you're getting hundreds or more it's going to be a real issue (breakage, security and so on). Despite that I think it's great that you want to step up and maintain this port, thanks! I see that danfe@ already picked it up :-) Best regards, Daniel
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=08f9c9628a8bb915eebda553dde944d3dd01c465 commit 08f9c9628a8bb915eebda553dde944d3dd01c465 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2021-07-08 10:14:36 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2021-07-08 10:14:37 +0000 ftp/wzdftpd: resurrect^Wreadd previously deleted port Despite that original author stopped working on the project, it has its userbase and remains fairly popular and demanded, known for its versatility and capabilities, so: - Bring back from the attic and fix the build with -fno-common - Mark OPENSSL option as BROKEN for the time being - Expand the default options a bit to get more useful package - Tighten one regex (escape the dot) and kill stray backslash - Fix a typo and adjust WWW line in the port description text - Submitter assumes maintainership of the port (thanks!) PR: 256840 Submitted by: Robert Clausecker MOVED | 1 - ftp/Makefile | 1 + ftp/wzdftpd/Makefile (new) | 94 +++++++++++++++ ftp/wzdftpd/distinfo (new) | 3 + ftp/wzdftpd/files/patch-ac-helpers__tls.m4 (new) | 11 ++ .../files/patch-libwzd-core_wzd_tls.c (new) | 52 ++++++++ ftp/wzdftpd/files/wzdftpd.in (new) | 25 ++++ ftp/wzdftpd/pkg-descr (new) | 19 +++ ftp/wzdftpd/pkg-plist (new) | 131 +++++++++++++++++++++ 9 files changed, 336 insertions(+), 1 deletion(-)
...and if we want to revive this the Makefile needs some work Having a quick look (there's probably more): PORTVERSION --> DISTVERSION (preferably) Overall ordering is a bit weird, please use portlint and/or portfmt _USES and _LIBS should be defined before _CONFIGURE (dependencies) Unless there's a very good reason for it drop IPv6 option and enable it unconditionally because we already have everything else IPV6 ready by now. If OpenSSL doesn't work and there is no intention in getting it working again just remove the option. Drop static libraries The post-patch section can probably also be cleaned up a bit Best regards, Daniel
(In reply to Daniel Engberg from comment #9) > PORTVERSION --> DISTVERSION (preferably) Nah. > Overall ordering is a bit weird, please use portlint and/or portfmt It's fine. > _USES and _LIBS should be defined before _CONFIGURE (dependencies) True, but that would create extra churn and add unnecessary noise to the diff. > Unless there's a very good reason for it drop IPv6 option and enable it It's on by default, so let's just leave an option for those who want to disable it for some reason. > If OpenSSL doesn't work and there is no intention in getting it working I'll try to fix it in a separate commit. > Drop static libraries Probably, I'll think about it. > The post-patch section can probably also be cleaned up a bit Probably, but not a big deal (that is, should be cleaned up together with some functional fix).
(In reply to Daniel Engberg from comment #9) Hi Daniel, Thanks for the remarks! I had tried to change as little as possible to make the patch easier to review. I'm going to look into these issues and submit another patch later with fixes. Also planning to revive OpenSSL support if doing so is feasible. I agree that FTP is on its way out, but there are still some important use cases (such as sharing trees of files with the general public).
(In reply to Robert Clausecker from comment #11) > Also planning to revive OpenSSL support if doing so is feasible. I've unbroken the build against OpenSSL in recent commit, but could not test in working environment; it would be nice if you could do that. I've also enabled PAM support and dropped those static libraries like Daniel had suggested.
(In reply to Alexey Dokuchaev from comment #12) Thanks, but next time please either take over maintainership or let me have a look at the patch in advance. It is difficult working on improving a port if other people commit random changes to it. That said, there appears to have been some work on the project for about two years after the final release, but no further release had been made. I am in contact with the primary author on how to proceed here.
(In reply to Robert Clausecker from comment #13) > It is difficult working on improving a port if other people commit random changes > to it. Those were not random changes, and they were quite limited and localised; if anything, they'd *ease* any future work, not make it more complicated. We typically reserve the right to modify the maintainer's submission to better match existing policies (or when unbreaking the build) without explicit blessing from the submitter or the maintainer.
(In reply to Alexey Dokuchaev from comment #14) I am aware of that. However, you had already committed the port so I was of the impression that all such changes had been performed in the commit. And the problem is not that you have done the changes but rather that I have not received any notice that you did so. You didn't even refer to this PR in the commit message, so there's no cross-reference to commit. It's just confusing because I likely wouldn't have noticed for a while.
(In reply to Robert Clausecker from comment #15) > You didn't even refer to this PR in the commit message, so there's no > cross-reference to commit. I've considered referencing it at first, but then decided that it would be a bit far too stretched. However, I certainly *did* want to notify you, hence comment #12. > It's just confusing because I likely wouldn't have noticed for a while. Understood, but then again, I've foreseen it and deliberately left a notice. That said, I'm happy that you're in touch with upstream and won't step on your toes, I'm sorry if I've left that feeling. I'm always happy to see FTP ports getting more attention and care, please keep it up!