Hi, Am Samstag, den 22.11.2014, 13:08 +0100 schrieb Bastien ROUCARIES: > > note that Haskell packages are rebuilt anyways when there is a > > (relevant) change to dependencies; this is handled using a tight system > > of virtual packages containing ABI hashes so, when a library changes, > > all libraries depending on it also change. > > No i means how during upgrade do you avoid to be linked to two > different version. replacement of library is not atomic (one library > is atomic). > See "Why RPATH is an issue" There is no problem here with two different versions, as Haskell libraries have their version name in the so name. So if, for some reason, two versions of the same library are linked into the same process, nothing breaks. > > Also, I’m not sure why there would be less breakage just because the .so > > file lies in the global library search path, instead of a private path > > pointed to by an rpath entry. > > What point to a private library ? i publiclibrary ? An executable ? Sorry, I can’t parse your question. > > Additionally, we want to use the default mode to stay on the well-tested > > code paths and avoid Debian specific bugs. > > I do not get your point here by default autoconf install under /usr/local/ > > Could you explain on debian-devel your plan with haskwell library. How > they are safe to upgrade (particularly partial). And why you need to > use rpath ? Sigh. This is leading nowhere. How can I explore the design space if I cannot even upload packages to experimental? I guess I’ll simply add the overrides. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part