Bug#770376: Allow rpaths in /usr/lib/ghc/
Hi, Am Freitag, den 21.11.2014, 19:22 +0100 schrieb Niels Thykier: 1. Could you explain how can I detect ghc package ? They are usually named libghc-.*-dev, but I think it is safer to match on the target of the rpath: If it is in /usr/lib/ghc/, it is ok. 2. Could you pin point to some documentation about this shared library stuff ? http://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared-libs.html#finding-shared-libs-unix 3. Could you explain why rpath and improve wiki (https://wiki.debian.org/RpathIssue) particularly with the issue here does not apply in your case. 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 can amend the wiki once a decision has been made. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#770376: Allow rpaths in /usr/lib/ghc/
On Sat, Nov 22, 2014 at 12:29 PM, Joachim Breitner nome...@debian.org wrote: Hi, Am Freitag, den 21.11.2014, 19:22 +0100 schrieb Niels Thykier: 1. Could you explain how can I detect ghc package ? They are usually named libghc-.*-dev, but I think it is safer to match on the target of the rpath: If it is in /usr/lib/ghc/, it is ok. 2. Could you pin point to some documentation about this shared library stuff ? http://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared-libs.html#finding-shared-libs-unix 3. Could you explain why rpath and improve wiki (https://wiki.debian.org/RpathIssue) particularly with the issue here does not apply in your case. 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 ? Bastien I can amend the wiki once a decision has been made. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770376: Allow rpaths in /usr/lib/ghc/
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 nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#770376: Allow rpaths in /usr/lib/ghc/
On Sat, Nov 22, 2014 at 12:43 PM, Joachim Breitner nome...@debian.org wrote: 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. 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 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 ? 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 ? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770376: Allow rpaths in /usr/lib/ghc/
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 nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#770376: Allow rpaths in /usr/lib/ghc/
control: tags -1 + moreinfo On Thu, Nov 20, 2014 at 9:03 PM, Joachim Breitner nome...@debian.org wrote: Package: lintian Version: 2.5.30+deb8u2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I just tried to upload a Haskell package built with ghc-7.8, but it was rejected: libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/ghc-prim-0.3.1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/integer-gmp-0.5.1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/transformers-0.3.0.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/base-4.7.0.1', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/rts-1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. GHC-7.8 (in experimental) started to also create shared libraries, but these live in private paths, so it uses rpath allow the linker to find them. It seems to me that this is a valid use of rpath 1. Could you explain how can I detect ghc package ? 2. Could you pin point to some documentation about this shared library stuff ? 3. Could you explain why rpath and improve wiki (https://wiki.debian.org/RpathIssue) particularly with the issue here does not apply in your case. Bastien I could start to create override files and add them to ~700 packages, but it seems to make more sense to make lintian aware of this use, and do not report this error for rpaths pointing to something in /usr/lib/ghc/. I mark this as important as it prevents us from uploading further Haskell packages to experimental (at least without temporary work-arounds). Thanks, Joachim - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.24.90.2014-2 ii bzip2 1.0.6-7+b1 ii diffstat 1.58-1 ii file 1:5.20-2 ii gettext0.19.3-1 ii hardening-includes 2.7 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b2 ii libarchive-zip-perl1.39-1 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.37-1+b1 ii libdpkg-perl 1.17.21 ii libemail-valid-perl1.195-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-2+b1 ii libparse-debianchangelog-perl 1.2.0-1.1 ii libtext-levenshtein-perl 0.11-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.64-1 ii man-db 2.7.0.2-3 ii patchutils 0.3.3-1 ii perl [libdigest-sha-perl] 5.20.1-3 ii t1utils1.38-1 Versions of packages lintian recommends: ii libautodie-perl 2.25-1 ii libperlio-gzip-perl 0.18-3+b1 ii perl5.20.1-3 ii perl-modules [libautodie-perl] 5.20.1-3 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.17.21 ii libhtml-parser-perl3.71-1+b3 ii libtext-template-perl 1.46-1 ii libyaml-perl 1.13-1 ii xz-utils 5.1.1alpha+20120614-2+b1 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRuSP4ACgkQ9ijrk0dDIGz51wCgkQZOTfg3npjwFZfLAX0FNmP1 MCwAoJ4kDPK+Zj79/MUB67yDnar6vxSo =D5ct -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject
Bug#770376: Allow rpaths in /usr/lib/ghc/
On 2014-11-21 19:04, Bastien ROUCARIES wrote: control: tags -1 + moreinfo Hi Bastien, Perhaps it is just me, but I am missing a reason of why this one is tagged moreinfo. ~Niels (Original mail quoted below): On Thu, Nov 20, 2014 at 9:03 PM, Joachim Breitner nome...@debian.org wrote: Package: lintian Version: 2.5.30+deb8u2 Severity: important Hi, I just tried to upload a Haskell package built with ghc-7.8, but it was rejected: libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/ghc-prim-0.3.1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/integer-gmp-0.5.1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/transformers-0.3.0.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/base-4.7.0.1', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/rts-1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. GHC-7.8 (in experimental) started to also create shared libraries, but these live in private paths, so it uses rpath allow the linker to find them. It seems to me that this is a valid use of rpath 1. Could you explain how can I detect ghc package ? 2. Could you pin point to some documentation about this shared library stuff ? 3. Could you explain why rpath and improve wiki (https://wiki.debian.org/RpathIssue) particularly with the issue here does not apply in your case. Bastien I could start to create override files and add them to ~700 packages, but it seems to make more sense to make lintian aware of this use, and do not report this error for rpaths pointing to something in /usr/lib/ghc/. I mark this as important as it prevents us from uploading further Haskell packages to experimental (at least without temporary work-arounds). Thanks, Joachim [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770376: Allow rpaths in /usr/lib/ghc/
On 2014-11-21 19:15, Niels Thykier wrote: On 2014-11-21 19:04, Bastien ROUCARIES wrote: control: tags -1 + moreinfo Hi Bastien, Perhaps it is just me, but I am missing a reason of why this one is tagged moreinfo. ~Niels [...] Never mind, found it: 1. Could you explain how can I detect ghc package ? 2. Could you pin point to some documentation about this shared library stuff ? 3. Could you explain why rpath and improve wiki (https://wiki.debian.org/RpathIssue) particularly with the issue here does not apply in your case. Bastien ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770376: Allow rpaths in /usr/lib/ghc/
Package: lintian Version: 2.5.30+deb8u2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I just tried to upload a Haskell package built with ghc-7.8, but it was rejected: libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/ghc-prim-0.3.1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/integer-gmp-0.5.1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/transformers-0.3.0.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/base-4.7.0.1', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. libghc-mtl-dev: lintian output: 'binary-or-shlib-defines-rpath usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.8.3/mtl-2.1.3.1/libHSmtl-2.1.3.1-ghc7.8.3.so /usr/lib/ghc/rts-1.0', automatically rejected package. libghc-mtl-dev: If you have a good reason, you may override this lintian tag. GHC-7.8 (in experimental) started to also create shared libraries, but these live in private paths, so it uses rpath allow the linker to find them. It seems to me that this is a valid use of rpath. I could start to create override files and add them to ~700 packages, but it seems to make more sense to make lintian aware of this use, and do not report this error for rpaths pointing to something in /usr/lib/ghc/. I mark this as important as it prevents us from uploading further Haskell packages to experimental (at least without temporary work-arounds). Thanks, Joachim - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.24.90.2014-2 ii bzip2 1.0.6-7+b1 ii diffstat 1.58-1 ii file 1:5.20-2 ii gettext0.19.3-1 ii hardening-includes 2.7 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b2 ii libarchive-zip-perl1.39-1 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.37-1+b1 ii libdpkg-perl 1.17.21 ii libemail-valid-perl1.195-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-2+b1 ii libparse-debianchangelog-perl 1.2.0-1.1 ii libtext-levenshtein-perl 0.11-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.64-1 ii man-db 2.7.0.2-3 ii patchutils 0.3.3-1 ii perl [libdigest-sha-perl] 5.20.1-3 ii t1utils1.38-1 Versions of packages lintian recommends: ii libautodie-perl 2.25-1 ii libperlio-gzip-perl 0.18-3+b1 ii perl5.20.1-3 ii perl-modules [libautodie-perl] 5.20.1-3 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.17.21 ii libhtml-parser-perl3.71-1+b3 ii libtext-template-perl 1.46-1 ii libyaml-perl 1.13-1 ii xz-utils 5.1.1alpha+20120614-2+b1 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlRuSP4ACgkQ9ijrk0dDIGz51wCgkQZOTfg3npjwFZfLAX0FNmP1 MCwAoJ4kDPK+Zj79/MUB67yDnar6vxSo =D5ct -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
