libesmtp-1.0.6 archive differs from original on http://brianstafford.info/libesmtp
tru7 opened this issue · 10 comments
Hi Brian, interesting reading of Retrospective on https://libesmtp.github.io/. Glad you are back.
As you mentioned libesmtp-1.0.6 is included in all kind of distributions based on the original version on http://brianstafford.info/libesmtp and former site.
Unfortunately the release 1.0.6 on https://github.com/libesmtp does not contain the same content which is kind of confusing and probably prevents people from updating the repo link to the new official site. Would be helpful if this could be fixed somehow. Maybe you could just host the original files in Download section on libesmtp.github.io?
Here is another link with your original tar files: https://ftp.osuosl.org/pub/blfs/conglomeration/libesmtp/
Good to hear. Here you have another reference to your old download files: http://www.linuxfromscratch.org/blfs/view/8.3/general/libesmtp.html. the md5 hash matches for the file from https://ftp.osuosl.org/pub/blfs/conglomeration/libesmtp/. So you should definitively be able to recover the widely spread version 1.0.6.
BTW I'm maintaining the libesmtp package on https://github.com/openwrt/packages in tree/master/libs/libesmtp. I was just informed yesterday that your old site had disappeared.
I've updated the repository and the website to reflect the issues outlined above.
At least for v1.0.6 the differences were minor and none affect source code consistency. However it turns out that I missed an important issue wrt configure.in vs configure.ac for older releases (which didn't affect 1.0.6).
I've added a libesmtp-1.0.6 branch to address the inconsistencies and explain these in more detail on the download page and on a new errata.html page linked from there. I feel this should be enough to address any concerns between the widely distributed 1.0.6 tarball and the repository.
Thank you so far. Most linux distributions have a copy of the original libesmtp-1.0.6.tar.bz2 to be able to rebuild the package for each new release. But they still refer to the old download link at http://brianstafford.info/libesmtp/libesmtp-1.0.6.tar.bz2 or even http://www.stafford.uklinux.net. For all of them it was much easier to just update the reference URL to something working to point to the exact same file as before. I don't think anyone will go for the branch libesmtp-1.0.6 in your new github repo. Without an easy way to download the (original) tarball noone will switch back to your official source repository. Just my two cents.
BTW: by switching to meson and dropping libesmtp-config probably noone will adopt new releases of libESMTP because it will break building definitions of all packages based on libesmtp. So libesmtp-1.0.7 won't be a drop-in replayement of libesmtp-1.0.6. At least for some time both libesmtp-config and libesmtp-1.0.pc would be needed so anyone building on libESMTP has a chance to update his package to move to pkg-config. But that's another story (issue).
BTW: did you try to regain the domain name brianstafford.info? Setting up a simple site to redirect to your new site would be very helpful.
But they still refer to the old download link at http://brianstafford.info/libesmtp/libesmtp-1.0.6.tar.bz2 or even http://www.stafford.uklinux.net.
I know but neither of those options are available. I can't even find a contact for the current owner of brianstafford.info so I'm unable to even request a redirection page as a courtesy.
I don't think anyone will go for the branch libesmtp-1.0.6 in your new github repo. Without an easy way to download the (original) tarball noone will switch back to your official source repository.
As you say the original tarball has incorrect links. A tarball created from the 1.0.6 branch with corrected links to GitHub and files generated by recent autotools would be the way to go.
BTW: by switching to meson and dropping libesmtp-config probably noone will adopt new releases of libESMTP because it will break building definitions of all packages based on libesmtp.
Eliminating autotools is something of a red line for me. I really am not prepared to maintain it since I don't use it often enough to have any level of expertise. I find autotools extraordinarily confusing and difficult to use or debug, particularly when it comes to m4 quoting. If you don't get all the files just right, out-of-tree builds or cross builds break. I'm not even sure if they work now. That becomes a real problem if I want to restructure source for any reason. It really is just too difficult to maintain.
Many projects are migrating to Meson/Ninja and are dropping autotools as soon as the meson build is stable. I'm surprised that dropping libesmtp-config in favour of pkg-config would be much of an issue nowadays, but it's not a problem to maintain if it really is a show-stopping issue.
All that said, if someone else is prepared to maintain autotools build during a transitional period that is fine.
So libesmtp-1.0.7 won't be a drop-in replayement of libesmtp-1.0.6. At least for some time both libesmtp-config and libesmtp-1.0.pc would be needed so anyone building on libESMTP has a chance to update his package to move to pkg-config. But that's another story (issue).
I don't think there will be a 1.0.7 as such - I had released a 1.0.7rc1 about a decade ago to test the waters with a migration to gsasl for authentication, but got no feedback (if there is it will be a bug-fix line to 1.0.6, either a 1.0.8 or 1.0.6.x - partly why I added the libesmtp-1.0.6 branch). Gsasl has a different API than the auth-client code in libESMTP so such a release would be something like version 1.2 with development in v1.1 following contemporary conventions for dev vs release versioning.
I'm not even sure gsasl is the right authentication library to use; I haven't followed its development in recent years so I'm not sure if it supports current SASL mechanisms used in email. Crypto code needs to be developed by crypto experts so I feel that auth-client may be close to or at the end of the road as it certainly needs significant effort to be brought up to date (it might survive for NTLM if that is still a thing).
There are also a few issues with the API - for example attaching user data to libESMTP structures places unnecessary burden on the programmer when destroying structures leaving potential for memory leaks. Also the STARTTLS extension needs a little restructuring which would affect the semantics of some API calls.
Inevitably any or all of these will affect the API somehow and that means applications using libESMTP will need modification. This feels like the time to change the build.
I think I got your points.
For brianstafford.info this is what I get from whois:
Registry Registrant ID: CR407078269
Registrant Name: Registration Private
Registrant Organization: Domains By Proxy, LLC
Registrant Street: DomainsByProxy.com
Registrant Street: 14455 N. Hayden Road
Registrant City: Scottsdale
Registrant State/Province: Arizona
Registrant Postal Code: 85260
Registrant Country: US
Registrant Phone: +1.4806242599
Registrant Phone Ext:
Registrant Fax: +1.4806242598
Registrant Fax Ext:
Registrant Email: brianstafford.info@domainsbyproxy.com
If you regain the domain I can easily set up a redirected website if needed.
I think I was a good idea to keep a separate branch for libesmtp-1.0.6 where all needed fixes like for openssl can be applied and released. New development could then be made on 1.1 for example. This way all further releases on libesmtp-1.0.6 can serve as drop-in replacements so noone has to rework on his project.
You may even drop autotools for meson/ninja without a problem as long as libesmtp-config stays in the package. That's because other projects have written autotool config to check for esmtp-config. Building these projects will instantly break if the libesmtp package was replaced by a newer release with only libesmtp.pc or libesmtp-1.0.pc.
BTW your current libesmtp-1.0.6 branch does not contain an environment for meson/ninja nor a complete environment for autotools, it lacks of many .in files.
Your old repo libESMTP-old is still complete. Wouldn't it be a good idea to provide further 1.0.6 minor releases there to adopt changes demanded by libraries like openssl without futher development of libesmtp itself?
As I'm not a developper I can't give you advice for further development of libesmtp. Maybe you will get into contact with others on issue #2
If you regain the domain I can easily set up a redirected website if needed.
Not an option really, for financial reasons. I was paying for the web hosting and email from my own pocket and I couldn't justify the expense any longer. Also with Covid-19 my income is reduced so I will not be seeking to regain it.
You may even drop autotools for meson/ninja without a problem as long as libesmtp-config stays in the package.
Iibesmtp-config remains in the libesmtp-1.0.6 branch. It would make sense to add pkg-config support to 1.0.6 so that packages can migrate in due course. I'll take a view later whether it should be added back to master.
BTW your current libesmtp-1.0.6 branch does not contain an environment for meson/ninja nor a complete environment for autotools, it lacks of many .in files.
The missing files are automatically generated by autotools. It usually isn't a good idea to maintain these in a git repository as they vary wildly between versions of each of the autotools suite's programs. The ones in the 1.0.6 tarball are extremely out of date. They are usually regenerated using something like aclocal ; automake --add-missing ; autoconf . I can never remember the exact sequence of arguments or whether this is sufficient. Some projects come with an autogen.sh file that generates the configure script and Makefiles but I never did find out how to create one. My options are to either automate this or use Meson for 1.0.6 too.
Your old repo libESMTP-old is still complete. Wouldn't it be a good idea to provide further 1.0.6 minor releases there to adopt changes demanded by libraries like openssl without futher development of libesmtp itself?
No, because git is extremely useful for comparing revisions and merging across branches within a repository and many git tools and frontends make this easy to do. Comparing or merging across repositories is much more difficult and blame tracking is lost. I plan to remove libESMTP-old in due course.
Of course you are right regarding autotools and the (not) missing .in-files. I just verified. Indeed I'm just used to run bootstrap.sh or autogen.sh in most projects. I'm fine with your plans described above and I'll be happy to assist.
I'll sort out outstanding issues on the 1.0.6 branch when I get a chance.
Thanks.