Restructuring the download archive

[Iain Buclaw via D.gnu]

On 10 July 2015 at 14:45, Johannes Pfau via D.gnu <d.gnu at puremagic.com>
wrote:

> I thinks it's time to push some new binary releases to gdcproject.org
> (gcc-5, intrinsics for checkedint, ...). We should first get some structure
> into our download archive though: ftp://ftp.gdcproject.org/binaries/
>
> The first question is whether we can break old download links. I've
> hardcoded one or two toolchain URLs in the build scripts, but that could be
> changed easily.
>
>
>
I think we can break anything that isn't a short name (should be a symlink
on the server).  We need to keep at least these for Travis to continue
working.

http://ftp.digitalmars.com/LATEST_GDC

By all means, we can raise a PR with Travis to move it elsewhere, then
remove the rest of the old structure later.




> Another question is how exactly the new directory layout should look like.
> I think we definitely need host folders as a top-level structure:
>
> /binaries
>  |- x86_64-linux-gnu
>  |- x86_64-w64-mingw32
>  |- arm-linux-gnueabi
>
> Do we want to have the target as a directory? GCC version? Frontend
> version?
> I think the frontend version is usually more important for users than gcc
> version. So if we don't use the GCC version we still have two options.
> dmdversion/target or target/dmdversion:
>
> /binaries
>  |- x86_64-linux-gnu
>  |  |- 2.061
>  |  |  |- x86_64-w64-mingw32
>  |  |  |  |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz
>  |  |  |  |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz
>  |  |  |- arm-linux-gnueabi
>  |  |- 2.062
>  |- x86_64-w64-mingw32
>  |- arm-linux-gnueabi
>
> Another question: DMD frontend sub-releases in one folder?
> (2.061|2.061.1|2.061.2)
>
>
I think GCC releases should take precedence over D Frontend and
architecture IMO.  As that is the most recognisable (and important) aspect
of the name.

eg:

/binaries
 |- 4.8.4
 |  |- x86_64-linux-gnu
 |  |  |- gdc-4.8.4+2.061.2.tar.xz
 |  |  |- gdc-4.8.4+2.062.tar.xz
 |  |  |- gdc-4.8.4-arm-linux-gnueabi+2.061.2.tar.xz
 |  |  |- gdc-4.8.4-arm-linux-gnueabi+2.062.tar.xz
 |  |  |- gdc-4.8.4-x86_64-w64-mingw32+2.061.2.tar.xz
 |  |  |- gdc-4.8.4-x86_64-w64-mingw32+2.062.tar.xz
 |  |- arm-linux-gnueabi
 |  |  |- gdc-4.8.4+2.061.2.tar.xz
 |  |  |- gdc-4.8.4+2.062.tar.xz
 |  |- x86_64-w64-mingw32
 |  |  |- gdc-4.8.4+2.061.2.tar.xz
 |  |  |- gdc-4.8.4+2.062.tar.xz
  |- 4.9.2
 |  |- arm-linux-gnueabi
 |  |- x86_64-linux-gnu
 |  |- x86_64-w64-mingw32
  |- 5.1.0
 |  |- arm-linux-gnueabi
 |  |- x86_64-linux-gnu
 |  |- x86_64-w64-mingw32


I want to avoid a situation where there is both gdc-4.8.2-2.061.2-20140430
and gdc-4.8.2-2.061.2-20150430 in the same directory.  We are already
overcrowding the name with a version number pair, adding in a timestamp
just makes it unreadable.

So, rather than having timestamps, I think we should just co-ordinate our
binary releases around GCC major and minor updates.  My preference being,
if we really must push in an update tarball whose GCC/DMD version pair is
already on our FTP server, I'd rather just overwrite the previous version,
maybe moving the original into an old-releases directory.

Regards
Iain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20150710/2ee89427/attachment.html>