thanks
hppa stable
ppc stable
x86 stable
amd64 stable
I'm not sure if it is worth doing anything about it, but 3.0 still does some things better than 4.0. Note that 4.0 is basically a complete redesign and rewrite, and as near as I can tell the only common code between them is the gentoo-specific repcacheman tool that is completely unknown upstream. 3.0 appears to have been pounded on and audited much more thoroughly than 4.0. Both versions appear to be dead upstream. 3.0 advantages: - Has code to protect against requests such as "GET /../../../../any/file/on/your/server", regardless of configuration (flat or not). (For 4.0, see also bug 524208, and upstream links eventually reach my 4 year old bug report https://github.com/gertjanvanzwieten/replicator/issues/4 , although there hasn't been any response to my bug report.) - Properly uses case-insensitive logic for HTTP header names, matching the relevant RFCs. - The ebuild includes the 3.0 patch from bug 442874 to handle the "x-unique-cache-name" custom header from portage, if supplied. - The ebuild logs a few more instructions (in the absense of real documentation). - Print some useful suggestions if you try to start it without having run repcacheman first (another patch included at the same time as bug 442874 changes). 4.0 advantages: - If upstream ever wakes up, they are probably more likely to work on 4.0 than 3.0. - Arguably cleaner internal design. - Apparently one or more gentoo patches have been added to 4.0 in the ebuild, including bug fixes for IPv6 support. - Unsure: Maybe HR-4.0 is closer to supporting python 3.x than HR-3.0, although the shared repcacheman script still requires python 2.x (see also bug 504538). I did write a second "x-unique-cache-name" patch for 4.0 in bug 442874, comment 18 (where I also mentioned these other issues), but it hasn't been incorporated. Historically, after I saw that 4.0 wasn't trying to handle the above obvious details properly (case sensitive, ".."s), I stopped looking for more issues, concluded 4.0 really needed a lot more auditing / attention to detail before it could leave "alpha" status and actually be safely deployed, wrote the above upstream bug report link, and figured I would ignore 4.0 until/unless someone invested that attention to detail in it. Now it is apparently considered stable without such attention... I wonder if maybe 3.0 should remain in the tree (or put back in the tree?) until/unless 4.0 includes the missing functionality? Or does no one want to worry about it?
The 4.0 releases do not implement --alias and a production deployment here at LINX failed upon upgrade. I am reinstating a 3.0 release.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97f0d18a976f63155e49686779c9eb75d539fa8a commit 97f0d18a976f63155e49686779c9eb75d539fa8a Author: Tony Vroon <chainsaw@gentoo.org> AuthorDate: 2019-02-28 12:03:28 +0000 Commit: Tony Vroon <chainsaw@gentoo.org> CommitDate: 2019-02-28 12:03:28 +0000 net-proxy/http-replicator: Revert 3.0 branch removal This reverts commit 3b8b8f6ec45e0220e5b841c96f89f52c6c5e02a5. The 4.0 branch does not implement --alias which means it is not a drop-in replacement to 3.0 in all cases. Please speak to me or file me a bug if you have any change requirements for the 3.x branch ebuilds. I will action them. Requested-By: Matthew Ogilvie Signed-Off-By: Tony Vroon <chainsaw@gentoo.org> Closes: https://bugs.gentoo.org/676758 net-proxy/http-replicator/Manifest | 1 + .../http-replicator-3-missing-directory.patch | 51 ++++++++++++ .../http-replicator-3-unique-cache-name.patch | 31 ++++++++ .../files/http-replicator-3.0-sighup.patch | 20 +++++ .../http-replicator/files/http-replicator-3.0.conf | 46 +++++++++++ .../http-replicator/files/http-replicator-3.0.init | 20 +++++ .../http-replicator/http-replicator-3.0-r7.ebuild | 93 ++++++++++++++++++++++ 7 files changed, 262 insertions(+)
(In reply to Larry the Git Cow from comment #7) > Please speak to me or file me a bug if you have any change requirements > for the 3.x branch ebuilds. I will action them. Wouldn't it be safer to get the package then? That way you will review all changes and fixes to it :/
