Hi, Am Samstag, den 22.11.2014, 12:38 +0100 schrieb Bastien ROUCARIES: > > Because I believe this falls under the exception > > > > Currently, the only generally accepted use of this feature in > > Debian is to add non-standard library path > > (like /usr/lib/<package>) to libraries that are only intended to > > be used by the executables or other libraries within the same > > source package. > > > > with the small twist that they are not all built from the same source > > package, but in all cases it is the single "ghc" package that decides on > > these locations and handles the rpaths. > > I do ot understand this part. it is ld.so that found library. > > So if so library change package during upgrade you are burned. Why do > you use the deploy mode ? 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. 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. Additionally, we want to use the default mode to stay on the well-tested code paths and avoid Debian specific bugs. 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