On Thu, Apr 14, 2016 at 1:12 AM, Sven Joachim <svenj...@gmx.de> wrote:
> Hi Roger,
>
> sorry for not having replied last week, I was busy with other things.

Dear Sven,

Sorry about previous push.
Obviously there's still issue I didn't notice, and didn't resolve yet.

> 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.*

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.
So I get lost completely.

>> I find another way, may be considered tricky though.
>> 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.

If you don't accept that, we have to find out the perfect/clean solution..

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Reply via email to