Joachim Breitner <[email protected]> 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/[email protected]/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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
