On 27.08.2017 13:37, Helmut Grohne wrote: > Source: binutils > Version: 2.29-7 > Severity: wishlist > User: [email protected] > Usertags: rebootstrap > > Hi Matthias, > > thanks for merging my binutils-for-host patches. I looked at the > resulting packages and found a couple of remaining issues. The attached > patch addresses them. > > 1. I forgot to remove the dependency from binutils-<triplet> on > binutils. You indicated that it may be necessary to ensure > availability of ldscripts, but using that dependency doesn't work. > Since binutils-<triplet> is Multi-Arch: foreign, you cannot tell > which binutils will be installed. Thus what you get is "some" > ldscripts for a semi-random architecture. The dependency simply needs > to go away.
we need that dependency for the man pages and the ldscripts. We can store the man pages in binutils-common then, and link to these. For the ldscripts see below. > You indicated that overlapping ldscripts should match across > architectures, so they could be installed into some m-a:same package. > That appears to contradict the comments in debian/rules telling the > contrary. What is correct here? > > Due to these conflicts, Debian's cross binutils have never provided > ldscripts. I haven't seen a single build failure due to missing > ldscripts (in over 3000 different cross builds). Thus I conclude that > it is best to say: If you need ldscripts, use "Build-Depends: > binutils". Otherwise, use binutils-for-host. Thus the dependency can > be removed. well, you are only cross building a subset of packages, and afaik not testing these. I'd like to avoid a "works for me only" approach. So yes, we should make the ldscripts available for the cross builds. we could do an upload with the ldscripts moved to the binutils-common package in keeping it as M-A: same. And then let the m-a checker see if those files differ. An alternative might be to install the ldscripts from the binutils-multiarch build into binutils-common. > 2. There is a typo in my patch 8, which causes d/control generation to > break when TARGET is set (i.e. targeted cross binutils). A sed > expression is missing an "@". fixed. > 3. In my patch, I was linking the documentation of binutils-for-host to > the documentation of its only dependency binutils-<triplet> to avoid > putting up another copy. Unfortunately, this is inappropriate for > packages marked Multi-Arch: same. If documentation linking is used > here, the same target must be used for all instances. I thus propose > to use binutils-common here. > > 4. binutils-common is marked Multi-Arch: same. The package really only > has architecture-independent files. The only (and good) reason to > make it Architecture: any is to avoid version skews due to buildd > timing. Thus the package should be marked Multi-Arch: foreign instead > to avoid users having to download it over and over again for multiple > architectures. This is not true anymore if we move the ldscripts into binutils-common. > If you want to stick with Multi-Arch: same, the binutils-common > package should simply be merged with libbinutils, because both are > implementation details. I can provide a patch for doing so. Just > using Multi-Arch: same on binutils-common doesn't make any sense. sure, but currently it doesn't hurt.
