Re: Moving to shared libraries?
Joachim Breitner <nomeata@debian.org> writes:
>> And, of course, there are all the other reasons that usually
>> recommend shared libraries---getting security fixes without requiring
>> recompiles, etc.
>
> Unfortunately, the benefit of „no recompiles“ does not apply to
> Haskell.
In fact, I must say I was a little surprised at the and confused when I
first started installing Haskell -dev packages because it seemed like
things were set up to be installed in lockstep to a greater degree than
I've ever seen before---and I've been a Debian user since 1995, pre-ELF
shlibs, etc., and don't remember ever encountering anything like it.
In that situation my natural inclination is to question whther that is
truly a necessity imposed upon us by upstream, or one we've accidentally
imposed on ourselves---it seems contrary to the way the vast majority of
language handles these issues.
(All of which sounds like I'm being critical of you who've done all this
work, but please be assured, I'm just damned ignorant, and fairly
stubborn, and need to convince myself that this is how it needs to be;
hopefully I will not wear out my welcome in the process ;)
> The package id includes the version, so every version bump requires a
> recompilation, unless we leave the version at what it is, e.g. when
> adding a Debian patch. But even then it is likely the the patch will
> somehow affect the ABI, which includes the _definitions_ of
> _potentially_ inlined functions and force a recompilation.
Well, but, the package id is an artifact of how things are being
packaged for Debian, no? (Again, if you want to just throw up your hands
and say "read the source", I will totally understand)
I mean, I realize that upstream Haskell authors are perhaps not
sensitized to soname issues and such in the way that many C library
authors are, and that the compiler probably does a lot of mangling of
symbols behind the programmer's back---and that different versions of
GHC will probably produce different symbol mangling and so forth...but I
suspect there might still be a lot of latitude, which brings us to the
next item...
>> That said, it does sound like there are a lot of technical issues. I
>> wonder if some of the infrastructure that the C++ developers have used
>> to try to handle ABI changes could be helpful?
>
> I don’t know much about their infrastructure; can you tell us a bit
> more?
Well I don't pretend to be an expert on it *at all*, but there was a
long discussion on d-d in January regarding C++ shared libraries and
symbol compatibility and maintenance, which I *imagine* have some
similar challenges--- that the compiler does many arbitrary
transformations to the symbols in the library without the author's
participation or knowledge, which dramatically ups the ante in what's
involved in maintaining shared library compatibilty.
Russ Allbery did a write up of his investigations, which might be a
decent place to start if it's of interest:
http://www.mail-archive.com/debian-devel@lists.debian.org/msg300222.html
> If there is sufficient demand we could add -dyn packages for all
> libraries, this would allow you to build your applications dynamically
> locally. For -dyn packages, the recompilation problem is not a big
> problem, as we have to recompile it anyways for the -dev package. The
> cost ist mainly in mirror space and the extended build time, plus some
> work in configuring hlibrary.mk.
Well all I wanted for the moment was to know that there wasn't a violent
objection to the idea---and it seems like you at least are open to it.
Now to figure out if we can do it in a way that will reflect Debian's
commitment to doing things "right"---I don't want to see this done just
to make things more complex and harder, but to simplify and streamline.
Mike.
Reply to: