On Monday, 10 April 2017 at 14:21:43 UTC, Gerald wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
There are a two issues though that we will be facing in Debian
soon, and I would like to get some opinion and maybe
perspective on from the D community on them.
First I would like to say thank you for all the work you did in
getting Tilix packaged for Debian, it is very much appreciated.
While I'm not an expert in this topic I'll throw in my two
cents anyway :)
Thanks!
So to the topic at end, I tend to agree with Vladimir in that I
just don't see it as feasible to make every dependency a shared
library. Personally I would suggest that only libphobos and
libdruntime be managed as shared libraries by a distro.
Otherwise, any other dependencies used in DUB or elsewhere
would be statically compiled.
This would raise the maintenance effort for D software, and
require policy exceptions, which is something we won't do. It's
more likely that we'll see less D in the distro than going down
this route.
DUB is unusable for Debian packaging anyway, and alternatives
like Automake or Meson handle shared libraries really well, so in
itself there is no reason not to do it.
If in time a new D library ends up becoming a keystone
foundation for many packages it could be considered for
inclusion as a shared library. Otherwise, trying to manage
every DUB dependency as a potential shared library is a huge
amount of work and I don't feel most of them are mature or well
maintained enough to support this approach.
We'll take care of that, it's what we do as a distro and we have
a fair amount of experience in handling these kinds of upstream
projects.
The goal is to reduce the maintenance cost for things once they
are *in* the distro, any prior work to get it into the
distribution is very well invested.
That's why I have been writing a lot of Makefiles and Meson build
definitions lately.
If you just concentrate on compiler, libphobos and libdruntime,
you can have separate packages for each compiler toolchain
which was Arch does.
That's a necessity already and we do the same. But with an
unstable ABI the standard library is also affected, which would
trigger us to do Haskell-style versioning (which mangles
dependencies to depend on a virtual package containing a hash of
the GHC version), and that not only sucks but also requires quite
a lot of manpower.
It has a libphobos package for DMD and a liblphobos for LDC.
This then enables developers to specify the tool chain they
prefer without interference.
Yes, but that's not feasible for use *in the distribution itself*
as we can't just pick and choose the right compiler per package
if something up in the dependency chain was compiled with the
"wrong" compiler.
In addition to the question about D and C++. what do distros
typically do for Rust and Cargo dependencies, or Java and
Maven? Wouldn't that be a similar paradigm to D and DUB
dependencies?
Maven dependencies are also separated out into smaller packages
and maven (unlike dub) plays relatively well with Debian. It also
has no ABI issues and interface stability can be tracked. Rust
only has one compiler which strongly optimizes, so we don't have
the problem of choosing the right one. Cargo is/was an issue but
it's being worked on and seems to work well now:
https://wiki.debian.org/Teams/RustPackaging/Cargo
(not that I am not involved in Haskell, Rust or Java packaging).
Just because it makes sense: We do have an upstream guide showing
some best practices for upstream projects which help us to
maintain software for long periods. It also contains
language-specific advice and some general info which is valid for
all languages:
https://wiki.debian.org/UpstreamGuide
