On 2016-04-14 02:42 +0900, Roger Shimizu wrote:
> On Thu, Apr 14, 2016 at 1:12 AM, Sven Joachim <svenj...@gmx.de> wrote:
>
>> On 2016-04-13 23:19 +0900, Roger Shimizu wrote:
>>
>>> Dear Sven,
>>>
>>> On Sat, Apr 2, 2016 at 9:17 PM, Roger Shimizu <rogershim...@gmail.com>
>>> wrote:
>>>>
>>>> And here's patch v4.
>>>>
>>>> Changes v2:
>>>> - add udeb supoort to libncurses5
>>>> Changes v3:
>>>> - add "Priority: extra" to udeb in debian/control
>>>> - fix typo when calling dh_makeshlibs
>>>> Changes v4:
>>>> - remove udeb support for libncurses5, since it's not required by
>>>> screen-udeb
>>>
>>> I was always on armel boxes do the screen support for d-i, so I didn't
>>> find there's a problem on amd64 until yesterday.
>>> With the previous v4 patch, building packages for src:ncurses on ARCH
>>> amd64, then check the dependency of built udeb:
>>>
>>> $ dpkg-deb -I libtinfo5-udeb_6.0+20160319-2_amd64.udeb
>>> Depends: lib32tinfo5 (>= 6), libc6-udeb (>= 2.19)
>>
>> I see why: the debian/libtinfo5-udeb.install file installs files named
>> usr/lib/*/libtic.so.*, and unfortunately the multilib libraries match
>> that wildcard, so you end up with /usr/lib/32/libtic.so.5 in the udeb
>> which is not what we want.
>>
>>> It seems "lib32tinfo5" only exists on amd64 and ppc64.
>>> Then I tried to add "lib32tinfo5-udeb" support in debian/control and
>>> debian/rules, but built "lib32tinfo5-udeb" depend on libc6-i386, which
>>> is not udeb. So I decide not to choose this solution.
>>
>> Yes, the right solution is not to install these files into the udeb in
>> the first place. This could be achieved by creating
>> libtinfo5-udeb.install from libtinfo5-udeb.install.in, as in the first
>> version of your patch.
>
> Thanks for your comment!
>
> I tried to remove install add install.in:
>
> diff --git a/debian/libtinfo5-udeb.install.in
> b/debian/libtinfo5-udeb.install.in
> new file mode 100644
> index 0000000..b0b4373
> --- /dev/null
> +++ b/debian/libtinfo5-udeb.install.in
> @@ -0,0 +1,2 @@
> +usr/lib/${DEB_HOST_MULTIARCH}/libtinfo.so.* lib/${DEB_HOST_MULTIARCH}
> +usr/lib/${DEB_HOST_MULTIARCH}/libtic.so.*
Apparently you have to install the libraries directly into lib/ and
avoid the multiarch directories in the udeb.
> and register the install:
>
> --- a/debian/rules
> +++ b/debian/rules
> @@ -69,8 +69,8 @@ DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture
> -qDEB_HOST_MULTIARCH)
> autogen-files := debian/libncurses5-dev.links debian/libtinfo-dev.links \
> debian/libncurses5.install debian/libncursesw5.install \
> debian/libncurses5-dev.install debian/libncursesw5-dev.install \
> - debian/libtinfo5.install debian/libtinfo-dev.install \
> - debian/libtermcap.so
> + debian/libtinfo5.install debian/libtinfo5-udeb.install \
> + debian/libtinfo-dev.install debian/libtermcap.so
>
> But the result of built package keeps the same.
> It still depends on lib32tinfo5, which is not udeb.
>
> I also confirmed that there's no "/usr/lib/32" library in the udeb.
> Library so files looks alright in udeb.
Huh, indeed. Looks like something is rather odd with dpkg-shlibdeps,
however this can be avoided by putting the libraries into lib/ (see
above).
>>> I find screen actually uses libtinfo.so, but not uses libtic.so, which
>>> includes in libtinfo5-udeb.
>>> After I applied the patch below to removed libtic.so from
>>> libtinfo5-udeb, the dependency becomes normal as ARCH armel:
>>>
>>> $ dpkg-deb -I libtinfo5-udeb_6.0+20160319-2_amd64.udeb
>>> Depends: libc6-udeb (>= 2.19)
>>>
>>> diff --git a/debian/libtinfo5-udeb.install b/debian/libtinfo5-udeb.install
>>> index c6aa24a..576962e 100644
>>> --- a/debian/libtinfo5-udeb.install
>>> +++ b/debian/libtinfo5-udeb.install
>>> @@ -1,2 +1 @@
>>> usr/lib/*/libtinfo.so.*
>>> -usr/lib/*/libtic.so.*
>>
>> I don't like that, since the information in the libtinfo5 shlibs file
>> information then becomes incorrect. The shlibs file says that udebs
>> with binaries linking to libtic should depend on libtinfo5-udeb, but
>> libtinfo5-udeb would not actually contain the library.
>
> Understand your points.
> But I can argue that udeb is the deb package only contain the stuff
> necessary for d-i.
> Stuff d-i don't need can be removed.
It is correct that d-i does not currently need libtic, but if some udeb
package ever does it will end up installable but broken, a situation I
would rather not let happen.
Cheers,
Sven
