On 2013-11-28 19:25, Marco Leise wrote:

> Don't be so ignorant. The zip is broken for all Linux systems
> bug Debian. I thought that with D Version Manager you tried to
> support more than one Linux distribution...

Yes, I would like that. But if the the current zip is removed it will break _every_ platform.

I can't remember hearing anyone complain about the zip isn't working. The only complains I've heard of is with curl and perhaps some ancient libc version.

Removing the current zip doesn't fix the problem anyway, it only creates new ones. What's the harm in leaving it?

-- 
/Jacob Carlborg

On 2013-11-28 15:51, Dicebot wrote:

> We can leave old .zip as-is just make it explicit that it is legacy
> layout and only 100% expected to work on Debian-compatible distros. I
> really don't care how it is distributed as I am using git tag anyway -
> what I do care about are users having wrong expectations when they come
> to download page.

That's only what I wanted.

-- 
/Jacob Carlborg

On 2013-11-28 20:17, Jonathan M Davis wrote:

> The zip has nothing to do with the stability of D itself. It just has to do
> with the stalibity of how D is distributed, which is a completely different
> issue. I can see why you care about the zip, given that you wrote and maintain
> a tool which relies on it, but calling D unstable because we might change how
> we release it would be like calling KDE or gnome unstable, because they
> changed from distributing their code in tar.gz files to tar.bz2 files. How a
> program or library is distributed has nothing to do with the stability of the
> code itself.

So where do we draw the line, what's considered to be part of D, if the releases aren't.

-- 
/Jacob Carlborg

On 2013-11-28 20:44, H. S. Teoh wrote:

> I don't see what's the big deal with providing one zip per supported
> platform (and each Linux distro is to be considered a separate platform
> here), *and* a dmd_everything.zip for distributors who *want* to have
> everything in one (they are installing D onto a network of heterogenous
> machines, they're making a distribution CD, etc.).
>
> The default download *should* be the platform-specific zip / tarball /
> package, but there's no need to kill the all-inclusive zip that contains
> literally *everything*, for the people who want it for whatever reason.

Thank you. I agree.

-- 
/Jacob Carlborg

On 11/28/13 12:21 PM, Jacob Carlborg wrote:
> On 2013-11-28 19:25, Marco Leise wrote:
>
>> Don't be so ignorant. The zip is broken for all Linux systems
>> bug Debian. I thought that with D Version Manager you tried to
>> support more than one Linux distribution...
>
> Yes, I would like that. But if the the current zip is removed it will
> break _every_ platform.
>
> I can't remember hearing anyone complain about the zip isn't working.

There have been plenty of complaints that it's illogical to distribute all binaries in one archive.

> The only complains I've heard of is with curl and perhaps some ancient
> libc version.
>
> Removing the current zip doesn't fix the problem anyway, it only creates
> new ones. What's the harm in leaving it?

We'll probably keep it but not advertise it. But you're making a terrible argument - you want us to keep a bankrupt artifact just because you don't want to update your code.


Andrei

On Thursday, November 28, 2013 21:23:33 Jacob Carlborg wrote:
> On 2013-11-28 20:17, Jonathan M Davis wrote:
> > The zip has nothing to do with the stability of D itself. It just has to
> > do
> > with the stalibity of how D is distributed, which is a completely
> > different
> > issue. I can see why you care about the zip, given that you wrote and
> > maintain a tool which relies on it, but calling D unstable because we
> > might change how we release it would be like calling KDE or gnome
> > unstable, because they changed from distributing their code in tar.gz
> > files to tar.bz2 files. How a program or library is distributed has
> > nothing to do with the stability of the code itself.
> 
> So where do we draw the line, what's considered to be part of D, if the releases aren't.

D is the language specification, dmd is the reference implementation of the language, druntime is its standard runtime library, and Phobos is its standard library. I don't see how the format that dmd and the standard runtime and library are distributed in is at all "part of D." It's just how it's currently distributed.

You have a legitimate concern in that you have written a program which relies on how dmd is currently distributed, but I don't see how you can argue that that has anything to do with what D is.

And while I don't think that we should just willy-nilly change how we distribute dmd, I would point out that we never actually promised that anything about how dmd is distributed would always stay that way. dmd has been distributed as a zip, because that happens to be how Walter decided to do it, and there's technically no guarantee that we will continue to do so.

Now, the fact that a useful tool written by one of this community's well-known members and which is used by a number of folks in the community relies on the zip being put together the way that it's put together and named the way that it's name should be taken into consideration when we look at changing how dmd is distributed. But I think that you have to acknowledge that as useful as DVM is, it's relying on something that was never actually guaranteed. It just happens to be how we've done it up to now.

And a number of people have been clamoring for some time that we change how do it and that the zip makes no sense, so I find it unlikely that we will continue to distribute the zip as-is. Maybe we leave it as-is temporarily, but I think that there's a good chance that at some point, you're just going to have to change how DVM works if you want it to continue to function - particularly since the zip really doesn't make sense and makes less and less sense as time goes on (e.g. the shared library situation doesn't work at all with the zip, and soon enough that will be more than just Linux).

- Jonathan M Davis

On 2013-11-29 03:39, Andrei Alexandrescu wrote:

> We'll probably keep it but not advertise it. But you're making a
> terrible argument - you want us to keep a bankrupt artifact just because
> you don't want to update your code.

That's the standard argument, "can't remove/change this, will break backwards compatibility".

-- 
/Jacob Carlborg

On Tuesday, 26 November 2013 at 19:21:31 UTC, Andrei Alexandrescu wrote:
> On 11/26/13 11:13 AM, Iain Buclaw wrote:
>> Remembering to include '-lcurl' when importing std.net.curl is perhaps
>> one urk.  But this will be a no longer a problem if libphobos is built
>> shared.
>
> Interesting. Can we supply a pragma that automates the flag thingie?
>
> Andrei


It doesn't work: http://forum.dlang.org/thread/yosxnqziavcnnxkfhtgm@forum.dlang.org

On 11/29/13 5:47 AM, Jacob Carlborg wrote:
> On 2013-11-29 03:39, Andrei Alexandrescu wrote:
>
>> We'll probably keep it but not advertise it. But you're making a
>> terrible argument - you want us to keep a bankrupt artifact just because
>> you don't want to update your code.
>
> That's the standard argument, "can't remove/change this, will break
> backwards compatibility".

I'd say alternative installers are in a different category than user code. Anyhow, you are making a good point that if your tool is out there, others may be too.

Andrei

On 11/27/2013 12:07 AM, Andrei Alexandrescu wrote:
>
> My conclusion after this whole discussion: in the short term we need to
> have both Fedora and Debian builds. Then we'll move from there.

Right, different distributions => different shared libraries.