On Monday, 10 April 2017 at 23:43:04 UTC, David Nadlinger wrote:
> On Monday, 10 April 2017 at 23:27:35 UTC, Walter Bright wrote:
>> The next problem is that dmd occasionally changes the interface to the D runtime. […] I also do not know how the gdc/lds druntime
>> interfaces differ.
>
> Just to make this very clear to everybody reading this thread: It's not even just that, but also the fact that we guarantee API-, but not ABI-stability for Phobos. Every time we continue to improve the pure/nothrow/@nogc situation by marking up some more code, we are breaking the ABI, because the mangled names of the involved symbols change. The ongoing work on `scope` also breaks the ABI when enabled.

If you could change the SOVERSION with every one of these changes, or simply just tie it to the respective Phobos release, distributions would automatically do the right thing and compile all D code using Phobos against the new version.
This might give Phobos a large soversion or and ugly one like "2.074", but it would work.
(LDC's Phobos and GDC's Phobos already have a soversion set in Debian...)

Looking into Rust and Cargo Debian packaging, it looks like they are looking to go with source packages to work around the ABI issue:

"Because Rust doesn't have a stable shared-library ABI, and we don't want to rebuild every Rust library package for every architecture every time we upload a new version of rustc, we package library crates as source code, installed into /usr/share/cargo/registry/cratename-version/. Thus, the Debian "binary" package for a library crate contains the same source as the source package."

https://internals.rust-lang.org/t/debian-rust-packaging-policy-draft/4453

On Tuesday, 11 April 2017 at 00:47:34 UTC, Jonathan M Davis wrote:
> On Monday, April 10, 2017 23:08:17 David Nadlinger via [...]
> Also, what are we even looking to distribute in debian? I would have thought that the normal thing to do would be to build with dub, in which case, having the compiler and dub be debian packages makes sense but not really anything else. If you're looking to package an application that was written in D, then that becomes another question, but then if you just statically link it, the ABI compatibility problem goes away as does any need to package any D library dependencies.

You will have static-library packages which have the exact same ABI issues shared libraries have.
And yeah, this is obviously about stuff being built with D compilers in the distro, such as Tilix, BioD, AppStream Generator and all future things which might emerge and be useful to have in the OS.

On Tue, 2017-04-11 at 12:03 +0000, Matthias Klumpp via Digitalmars-d wrote:
> 
[…]
> Nah, there are several options here, one would simply be to tell
> people not to use the distro packages with anything but the
> default D compiler used in the respective Debian release.
> Go apparently tells people not to use Debian-shipped go code in
> their own projects at all.

The vendoring systems that Go folk have invented are effectively mandatory for projects that want reproducible builds, and using platform specific code is not feasible. It suprises me that Debian and Fedora are going flat out trying to package Go stuff.

-- 
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 Tue, 2017-04-11 at 12:38 +0000, Gerald via Digitalmars-d wrote:
> Looking into Rust and Cargo Debian packaging, it looks like they are looking to go with source packages to work around the ABI issue:
> 
> "Because Rust doesn't have a stable shared-library ABI, and we don't want to rebuild every Rust library package for every architecture every time we upload a new version of rustc, we package library crates as source code, installed into /usr/share/cargo/registry/cratename-version/. Thus, the Debian "binary" package for a library crate contains the same source as the source package."
> 
> https://internals.rust-lang.org/t/debian-rust-packaging-policy-draft/ 4453

So why bother, no Rust people will use it, they just use Cargo and it gets stuff for them. Why bother packaging anything when people will not use it? All you need to have a working Rust system on Debian is curl and bash.

-- 
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 Tuesday, 11 April 2017 at 12:42:13 UTC, Russel Winder wrote:
> On Tue, 2017-04-11 at 12:03 +0000, Matthias Klumpp via Digitalmars-d wrote:
>> 
> […]
>> Nah, there are several options here, one would simply be to tell
>> people not to use the distro packages with anything but the
>> default D compiler used in the respective Debian release.
>> Go apparently tells people not to use Debian-shipped go code in
>> their own projects at all.
>
> The vendoring systems that Go folk have invented are effectively mandatory for projects that want reproducible builds, and using platform specific code is not feasible. It suprises me that Debian and Fedora are going flat out trying to package Go stuff.

That's false. Debian is leading the effort on reproducible builds that many other projects (including Fedora) have joined, and a large chunk of packages is already reproducible[1].
It's actually quite the opposite: Build systems downloading random stuff from the internet make the system more likely to produce different build results.

But in any case, the primary use for Debian packages is to be used by the distribution.

[1]: https://tests.reproducible-builds.org/debian/reproducible.html

On Tuesday, April 11, 2017 12:40:34 Matthias Klumpp via Digitalmars-d wrote:
> On Tuesday, 11 April 2017 at 00:47:34 UTC, Jonathan M Davis wrote:
> > On Monday, April 10, 2017 23:08:17 David Nadlinger via [...] Also, what are we even looking to distribute in debian? I would have thought that the normal thing to do would be to build with dub, in which case, having the compiler and dub be debian packages makes sense but not really anything else. If you're looking to package an application that was written in D, then that becomes another question, but then if you just statically link it, the ABI compatibility problem goes away as does any need to package any D library dependencies.
>
> You will have static-library packages which have the exact same
> ABI issues shared libraries have.
> And yeah, this is obviously about stuff being built with D
> compilers in the distro, such as Tilix, BioD, AppStream Generator
> and all future things which might emerge and be useful to have in
> the OS.

My point was that there really isn't a reason to package D libraries in the distro. ABI compatibility makes including D libraries in a distro problematic, and dub takes care dependencies for you, making it completely unnecessary to include any D libraries in a distro. Now, there may be a reason to include a D _program_ in a distro, but with a D program, you can just build it with dub and statically link in its D libraries so that they don't need to be part of the distro. And if we go that route, you pretty much avoid this whole mess.

- Jonathan M Davis

On Tue, 2017-04-11 at 12:48 +0000, Matthias Klumpp via Digitalmars-d
wrote:
[…]
> That's false. Debian is leading the effort on reproducible builds
> that many other projects (including Fedora) have joined, and a
> large chunk of packages is already reproducible[1].
> It's actually quite the opposite: Build systems downloading
> random stuff from the internet make the system more likely to
> produce different build results.

You are closer the that community that I am and so have better knowledge there. My comment was really reflecting the cant about the OS packages.

> But in any case, the primary use for Debian packages is to be used by the distribution.

Where Debian and Fedora provide applications written in Go they will be statically linked. So is the use case that everything used to create the application has to be packaged?

> [1]: https://tests.reproducible-builds.org/debian/reproducible.html
-- 
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 Tuesday, April 11, 2017 12:25:09 Matthias Klumpp via Digitalmars-d wrote:
> Haskell and OCaml permanently rebuild the whole stack on every new compiler release, which is why they have permanent transition trackers[1], so they basically continuously rebuild. I want to avoid this at all cost for D, as this is very very maintenance intensive and painful, and will require much more people to work on it than D has available in Debian.

That's basically what's required with D. It is not ABI compatible across releases, and while ABI compatibility might be nice, it really isn't reasonable with D - especially with how attributes work and how template heavy D code is. If the D compiler gets upgraded, then anything that gets built needs everything that it depends on to have been built with that exact compiler version.

But if we just use dub - which _is_ the official packaging and build tool - then we avoid these issues. Ideally, the compiler and dub would be part of the distro, but libraries don't need to be. And it sounds like that's basically how the Go and Rust folks want to function as well. So, it would make sense for these languages to simply not have their libraries be included in distros. The build tools are plenty.

- Jonathan M Davis

On Tuesday, 11 April 2017 at 12:47:13 UTC, Russel Winder wrote:
> So why bother, no Rust people will use it, they just use Cargo and it gets stuff for them. Why bother packaging anything when people will not use it? All you need to have a working Rust system on Debian is curl and bash.

Users of an application written in Rust are not developers, they just want to install an app using whatever packaging mechanism the distro provides. Also, I would expect that the source library packages for Rust are likely just a build dependency and users are not building Rust binaries on their system. This is just a way for the Debian packagers to build packages and track dependencies using the tools and processes they already have in place.

Having said that, I don't disagree with you as I think it's a bit silly to replicate what cargo, maven and dub already provide OOTB and essentially duplicate their existing repositories. However, if Rust is going in this direction it can make sense for D to follow and just make the necessary improvements in Dub to support the process.