[boost] Final Notice: BinTray is shutting down 1-May (that's SATURDAY)
Marshall Clow via Boost
At that time, you will be unable to download boost releases from there.
Before that time, their service will be occasionally interrupted.
The web site has been updated, all the download links now refer to
https://boostorg.jfrog.io/artifactory/main/release/ <https://boostorg.jfrog.io/artifactory/main/release/>
Example:
Instead of downloading from:
https://dl.bintray.com/boostorg/release/1.76.0/source/boost_1_76_0.tar.gz <https://dl.bintray.com/boostorg/release/1.76.0/source/boost_1_76_0.tar.gz>
You should download from:
https://boostorg.jfrog.io/artifactory/main/release/1.76.0/source/boost_1_76_0.tar.gz <https://boostorg.jfrog.io/artifactory/main/release/1.76.0/source/boost_1_76_0.tar.gz>
This applies to all releases from 1.63.0 onward
(The pre-1.63 releases are still hosted at SourceForge)
— Marshall
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peppard via Boost
> Bintray is “sunsetting” on the 1st of May.
> At that time, you will be unable to download boost releases from there.
> Before that time, their service will be occasionally interrupted.
It would be nice if Boost could provide more persistent download URLs,
as such changes can mess up automated downloads (scripts, Dockerfiles, ...).
> (The pre-1.63 releases are still hosted at SourceForge)
Actually I'm currently using SourceForge for automated downloads as this
seems to be the only place where you can download all official releases
in a uniform manner, which is important when the version number is
merely a parameter. However it does not work for all betas and release
candidates, and it's an external service that could change anytime as well.
It's not necessary for Boost to host the actual downloads themselves,
but I think a redirect service to the actual download URLs would be good
for such use cases, ideally also covering betas and release candidates.
(Another problem regarding automated downloads are the missing
signatures, but that's probably too off-topic here.)
Thanks!
Marshall Clow via Boost
>
> On 2021-04-29 19:34, Marshall Clow via Boost wrote:
>> Bintray is “sunsetting” on the 1st of May.
>> At that time, you will be unable to download boost releases from there.
>> Before that time, their service will be occasionally interrupted.
>
> It would be nice if Boost could provide more persistent download URLs,
> as such changes can mess up automated downloads (scripts, Dockerfiles, ...).
Changing once in four years is “not persistent”?
— Marshall
Boris via Boost
>>> Bintray is “sunsetting” on the 1st of May.
>>> At that time, you will be unable to download boost releases from there.
>>> Before that time, their service will be occasionally interrupted.
>> It would be nice if Boost could provide more persistent download URLs,
>> as such changes can mess up automated downloads (scripts, Dockerfiles, ...).
> Changing once in four years is “not persistent”?
>
Peppard via Boost
>>>> Bintray is “sunsetting” on the 1st of May.
>>>> At that time, you will be unable to download boost releases from there.
>>>> Before that time, their service will be occasionally interrupted.
>>> It would be nice if Boost could provide more persistent download URLs,
>>> as such changes can mess up automated downloads (scripts,
>>> Dockerfiles, ...).
>> Changing once in four years is “not persistent”?
>>
> A URL redirecting script on boost.org would be more persistent.
Hopefully so, yes. But more importantly, by using an external service
you might be depending on them to decide whether the next change will be
in four years or tomorrow. And you're also restricting yourself, as it
makes switching to another provider more painful.
Also take a look what the current external service is doing, they are
forwarding (at least partially) to another third party, but their links
appear to be local.
Then finally - as I tried to argue initially as well - there currently
seems to be no uniform way to automatically download all official
releases and also the betas and release candidates, so persistence might
not be the only argument.
One thing I'm not quite sure about though is how that would impact the
(non-existing?) privacy policy. (OT: boost.org is using multiple third
parties - also not exactly privacy friendly ones -, so it should have a
privacy policy, no?)
Peter Dimov via Boost
> >>> It would be nice if Boost could provide more persistent download
> >>> URLs, as such changes can mess up automated downloads (scripts,
> >>> Dockerfiles, ...).
download.boost.org/boost-1.76.0/boost_1_76_0.7z
as a redirect.
On the other, we already have problems with spiders mirroring the
entire boost.org site along with all the downloads, and these problems
may be exacerbated by moving the URLs to boost.org (as they would
be on the same domain then.)
René Ferdinand Rivera Morell via Boost
wrote:
> Peppard wrote:
> > >>> It would be nice if Boost could provide more persistent download
> > >>> URLs, as such changes can mess up automated downloads (scripts,
> > >>> Dockerfiles, ...).
>
> On one hand, it does seem useful to provide e.g.
>
> download.boost.org/boost-1.76.0/boost_1_76_0.7z
>
> as a redirect.
>
> On the other, we already have problems with spiders mirroring the
> entire boost.org site along with all the downloads, and these problems
> may be exacerbated by moving the URLs to boost.org (as they would
> be on the same domain then.)
>
But with a redirector you could bounce such spiders at the early redirector
point.
--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net