[ Replying to lots of stuff in one message - evil, I know... ;-) ]
On Sunday, 9 September 2018 at 21:22:42 UTC, 9il wrote:
On Sunday, 5 August 2018 at 02:36:29 UTC, Matthias Klumpp wrote:[...]Looks like that only betterC projects are good enough to become Debian packages. Generally because of the have stable C ABI that does not depend on D compiler version at all.
Having a stable API/ABI is a *huge* plus, but we can also deal with pretty much any D library and D project in Debian, as long as it's build process is able to discover local dependencies and doesn't do evil stuff (like connecting to the network or writing to HOME). It also has to build with LDC or have no D library dependencies and build with GDC (that's a bit oversimplified though).
In practice this means we can have dub projects with zero dependencies (except for the standard library) that build only executables in Debian packages with a bunch of hacks, or have any D project that uses Makefiles/Meson/CMake/Automake.
Mir has the latter now, so that's fine. On Monday, 10 September 2018 at 06:31:44 UTC, Russel Winder wrote:
On Sun, 2018-09-09 at 21:22 +0000, 9il via Digitalmars-d-announce wrote:[...] Many Debian packages dependon specific versions of things like GCC runtime or LLVM. The Debian packaging system allows for many versions of libraries to co-exists. Thus supportingmultiple versions of Druntime and Phobos is possible.
It is possible, but heavily discouraged, and also not something I would ever even try to do. Debian carries *one* version of Phobos/DRuntime per compiler that we support and that all D code in the archive has to build with. There may be occasions where multiple versions are in the archive, but that happens only briefly during transitions. For security reasons (only one thing to patch in stable) and maintainability reasons (the less to maintain the better) anything that doesn't build with the current version of D/Phobos will either be patched upstream or in Debian or dropped from Debian entirely. So far this case has never happened though, all breakage of D code in Debian was usually addressed pretty quickly - except for strange compiler bugs on less common architectures.
[…]> I only worry about potential name clashes with Mir (the > display server) in Ubuntu ^^This is going to be a naming problem. Debian has many of these sort of naming clash and usually it is best for the smaller, newer project to accept that they need to choose a non-clashing name. Recent example the Mu editor, but there are many instances of this. D's Mir needs to choose a name that doesn't clash with Canonical's Mir.
This was more meant as a joke from my side ;-) Technically, nobody from Canonical bothered to upload a "mir" package to Debian yet, so technically the name is free to grab for us. However, introducing a src:mir package into Debian would either force Ubuntu to adapt and rename their display server source package (to mir-display-server) or not have D's mir for quite a while. Socially I think claiming the src:mir name isn't the best idea, therefore - it's unfriendly to a derivative. However, src:libmir is free and that's what we could go with as a pretty good compromise. As for the binary package names, none of the D-mir names clash with Ubuntu's mir, so that's a non-issue.
On Monday, 10 September 2018 at 07:25:07 UTC, 9il wrote:
On Monday, 10 September 2018 at 06:31:44 UTC, Russel Winder wrote:On Sun, 2018-09-09 at 21:22 +0000, 9il via [...]Interesting, maybe we can go forward with D specific libraries in the future. Is there any D library that is used by application packages?
Quite a few. Debian uses GDC and LDC for compiling its D packages. LDC on the amd64, arm64, armhf and i386 architectures and GDC on all other archs. The respective default D compiler is set via the default-d-compiler metapackage[1].
This means that whenever there's a new compiler release, ABI gets broken "thanks" to D's unstable ABI. Fortunately all new compilers also come with a new Phobos shared library that has had its SONAME bumped. Which means we can track which D compiler a package was built with via the phobos/druntime libraries they link to. This enables us to rebuild dependencies in order via a regular library transition, coincidentally one is going on right now. See[2] and tick "Good" to see all D packages that are part of this transition.
This results in the fun conundrum though that as soon as we have D code that *doesn't* link against druntime or phobos, we can't track whether it was rebuilt with the latest compiler and it might fall through the cracks. I wonder how much of an issue this is - other languages implemented hacks to deal with this issue by depending on artificial virtual ABI packages denoting the current compiler version.
Mir Optim can be easily used by other libraries and languages, developers don't need to know D at all as well as depend on DRuntime and D compiler.The problem with Compiler/DRuntime version that it seems like that if, for example one man released library A that is depend on DRuntime v1, and other man released library B that depends on DRuntime v2, how can I use them in my project together if this DRuntimes are not compatible at ABI level? Maybe we can link dynamically them together, but how GC will work then (in case of non BetterC library)?
In Debian, both libraries and all projects would either build with the latest DRuntime, be adjusted to build with it or be dropped from the distribution if they can't keep up.
So, this issue shouldn't exist.
If a solution of this issue exist, I would be very surprised if it is easy to go solution. betterC libraries with fixed ABI, and C/C++ API looks to me like a right way to develop D packages for Debian.
It certainly is nicer - but we deal with even worse languages than D when it comes to ABI instability. For example, Haskell and OCaml require a full rebuild of all packages even on minor compiler version changes. Therefore, virtual packages containing checksums of the compiler exist, it's quite insane. These languages are also in an eternal transition[3]. This works, because there are actually bigger teams behind those languages which can handle the work.
Which brings me to a new point:Adding libraries to Debian for their own sage is sometimes done if someone is using them / is interested in them in itself, but often they get pulled in because another tool that is in Debian needs them. Mir would be the former case, adding a library without something using it that's also in Debian. I like the Mir project, but since I am not using it at the moment (as scientist I actually might be tempted to do so in future) and since I already have way too many packages to care for, someone else would need to step up and do the packaging work and - more importantly - the maintenance work. While the Debian D team[4] officially lists 4 members, it's basically me doing all the work at the moment with Markos helping with LDC maintenance as its original maintainer. So, tl;dr: I will help with reviewing packages and sponsoring packages into Debian, but in order to get the package in, someone would need to step up and do the work.
FWIW, the Debian D Team is not the only entity withing Debian maintaining D code, the GNOME Team has gtk-d, glib-d and tilix and the Debian Games team also has a bunch of D stuff and a bit is also in the Debian Med/Science team, but the majority of D code is concentrated in the D team.
Cheers,
Matthias
[1]: https://packages.debian.org/sid/default-d-compiler
[2]: https://release.debian.org/transitions/html/auto-ldc.html
[3]: https://release.debian.org/transitions/html/haskell.html
[4]: https://salsa.debian.org/groups/d-team/
P.S: As for "D libraries in Debian", we have vibe.d, diet-ng,
libundead, stdx-allocator, mustache-d, containers, glib-d, gtk-d,
libbiod. Quite a bunch, actually!
