On Mon, 3 Jun 2013 17:12:31 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 03 Jun 2013 19:30:16 +0100
> Russel Winder <russel@winder.org.uk> wrote:
> > 
> > The start point has to be a tarball of the source. If this is not part of the distribution release then we need to agree an officially acceptable process for creating a release source tarball.
> > 
> 
> My tool will do this.
> 

Speaking of which: Are there any special requirements I should be aware of? In particular, it would be very helpful to have a canonical list of anything/everything that should be different from what you get by taking one of the current release ZIPs we have today and extracting it.

Also does ".tar.gz" vs ".tar.bz2" matter? I understand that the latter (if I spelled it right) is newer and better compression, but any reason that it might *need* to be one or the other?

On Monday, 3 June 2013 at 21:18:54 UTC, Nick Sabalausky wrote:
> Also does ".tar.gz"

I prefer tar.gz because bzip is SLOW. There's some space savings but meh.

gzip is slightly more likely to be already installed on a box too, though bzip is like 99% so that doesn't matter a lot.

I have two requests if we start changing the zip, since I'm pretty happy with it how it is!

1) keep the folder structure the same as it is now. So the windows zip still has a windows folder in it with the bin and lib stuff. The only difference from the current thing is you remove the linux etc folders.

This way we don't have to update install/use scripts that assume these paths exist.


2) still keep the zips for all the OSes available. I don't use a package manager and don't care for installers. I still want a dmd-windows.zip and dmd-linux.zip and so on. (or dmd-linux.tar.gz, whatever, as long as the contents are the same)

On Mon, 03 Jun 2013 17:21:30 -0400, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Monday, 3 June 2013 at 21:18:54 UTC, Nick Sabalausky wrote:
>> Also does ".tar.gz"
>
> I prefer tar.gz because bzip is SLOW. There's some space savings but meh.

+1 when developing an imaging system for hard drives using cpio+compression, bzip never finished running (well, I didn't wait long enough probably), plus it doesn't stream at all.

-Steve

On Monday, June 03, 2013 11:42:53 Jacob Carlborg wrote:
> On 2013-06-03 10:34, Jonathan M Davis wrote:
> > Well, part of the problem is that the zip is inherently broken for *nix systems due to the fact that symlinks don't work properly. So, now that we have an so version of Phobos, the zip just isn't going to work properly anymore. And while we aren't really looking to break DVM, AFAIK, there would be no other reason to keep the zip around other than for DVM. And since the zip isn't going to work properly on *nix systems anyway, I'm not sure that keeping it around for DVM really solves much.
> 
> *nix is really not correct to say. Currently only Linux 64bit supports shared libraries. It's not like it's broken on all platforms, just one. Sure, it will break once we get support for share libraries on additional platforms.
> 
> If static linking is default nothing is broken.

By default sure, but people can now use Phobos as a shared library if they so choose, and at some point, it will probably change to be the default. And the symlinks _are_ broken thanks to zip. And the problems will only get worse as we add more platforms. There's really no reason to stick with zip files other than avoiding breaking something like DVM, and the zip files are inherently broken at this point anyway. And that breakage will only get worse as we add more shared library support.

> Which format can we use for these platform specific packages?

We'd probably use tar.gz or tar.bz2, which are incredibly standard. Mac OS X might want something different (I don't use it, so I don't know), but it's based on the BSDs, so it probably uses tar.gz like the rest (I'm sure that it at least supports it). zip is too Windows-specific.

> For which of these are there existing bindings or libraries?

I'm sure that there are C bindings for tar and gz, but I've never used them, and worst case, it's trivial to use std.process.system to decompress the package.

- Jonathan M Davis

On Monday, June 03, 2013 16:59:16 Russel Winder wrote:
> Is there a tarball or only this infamous zipfile?

Only the zip file, which is the main reason why all of the symlinks are broken. But Nick is working on changing it so that we generate separate packages for each OS, and Brad Roberts has some preliminary pull requests towards creating install targets to generate the packages.

- Jonathan M Davis

On Monday, June 03, 2013 23:27:00 Adam D. Ruppe wrote:
> 2) still keep the zips for all the OSes available. I don't use a package manager and don't care for installers. I still want a dmd-windows.zip and dmd-linux.zip and so on. (or dmd-linux.tar.gz, whatever, as long as the contents are the same)

Well, they wouldn't be zip for stuff other than Windows (they'd likely be tar.gz or tar.bz2 for the other OSes), but their internals could be kept the same as far as directory structure goes.

- Jonathan m Davis

On Monday, June 03, 2013 14:13:26 Walter Bright wrote:
> On 6/3/2013 12:50 PM, Russel Winder wrote:
> > On Mon, 2013-06-03 at 12:38 -0700, Walter Bright wrote:
> >> On 6/3/2013 8:59 AM, Russel Winder wrote:
> >>> Is there a tarball or only this infamous zipfile?
> >> 
> >> I can't believe it is hard to create a tarball from a zipfile.
> > 
> > Actually it can be since tarballs can represent symbolic links whereas it appears zipfiles cannot.
> 
> 1. unzip the zip file
> 2. add symbolic links
> 3. create tarball

But why create it as a zip file in the first place? Just create the tarball correctly when it's built and don't create a zip file at all. Clearly, people other than you are going to be sorting this out, but we shouldn't even be creating a zip file for the non-Windows OSes in the first place. The symlinks should be created as part of the build and tar-ed from there.

- Jonathan M Davis

On Mon, 2013-06-03 at 14:13 -0700, Walter Bright wrote: […]
> 
> 1. unzip the zip file
> 2. add symbolic links
> 3. create tarball

Not the right way of doing it.

[…]
> It's already tagged with v2.063

1. clone repository
2. checkout to tag
3. generate tar.gz file

Definitely a better way.

The symlinks is only part of the issue re the Debian deb file.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2013-06-03 23:08, Nick Sabalausky wrote:

> I intend to. But I do think it would be good if we then update DVM
> to use the platform-specific versions, to preserve bandwidth and
> improve dload/installation speeds.

I would like to rewrite the whole tool. Then we can fix all these things. Haven't taken the time to do it yet.

> Possibly related to that, I keep meaning to look into updating DVM to
> install *both* -m32 and -m64 abilities on appropriate platforms (unless
> you've already beaten me to it?)

No, I haven't done that. See above.

BTW, DVM is not really working on Windows XP, or rather the installed compilers. DVM installs the compilers in a path which contains spaces. The compiler and/or the linker isn't happy with that.

-- 
/Jacob Carlborg