Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Felipe Sateler]

On 15 November 2016 at 18:17, Wookey  wrote:
> On 2016-11-15 15:53 -0300, Felipe Sateler wrote:
>> On Tue, 15 Nov 2016 17:22:12 + Wookey  wrote:
>> > Package: dpkg
>> > Version: 1.18.10
>> > Severity: normal
>> >
>> > I built a large package (mythtv) with this recipie:
>> > git clone https://github.com/MythTV/packaging -b fixes/0.28
>> > cd packaging/deb
>> > ./build-debs.sh fixes/0.28
>> >
>> > This all works fine until the dh_shlibdeps when packing it up at the
>> > end.
>> >
>> > which complains about missing dependency info for
>> > /usr/lib/ld-linux-armhf.so.3
>>
>> This is the same as #843073, so merging. Raphael has proposed a patch
>> on that bug, but it needs more testing before it is accepted.
>
> Right. Cheers for that. (I failed to check the dpkg bugs first because
> I started filing against glibc and checked that list, then realised
> part way through that this was best filed against dpkg).
>
> How is the usrmerge done? bind-mounting? hardlinks?

Softlinks. /bin => usr/bin, /sbin => usr/sbin , /lib => usr/lib,
/lib${multilib} => usr/lib/lib${multilib} .

> Is dpkg-shlibdeps the only thing that is going to wrong if files stop
> having a canonical location in the system? It's a pretty major change
> having every library (and a load of binaries?) appear twice? (Or do I
> misunderstand how this is implemented?).

Guillem pointed out on IRC that dpkg-query --search will also be confused.
For most things it shouldn't matter, as things will be where people expect
them. Some other programs are bound to be confused. systemd-delta, for
example, was also confused, but it was fixed already. To my knowledge,
dpkg-query --search and dlocate are the only ones (in fact, the problem in
dpkg-shlibdeps is because it uses dpkg-query --search).

> Like Guillem, I'd be a lot happier if files, especially libraries,
> only existed in the place they existed, and if we want to move that
> then we should move it in the packaging.

That would be great from my POV. However, it has some drawbacks: Stuff in
/bin cannot be moved to /usr/bin until /bin is a link to /usr/bin (ditto
sbin). Otherwise, for example fsck won't find the /sbin/fsck.$fs programs.
In general, way too many things hardcode paths in /bin or /sbin. So the
options are a period where package metadata does not match the filesystem,
or we have a long period of uninstallability until all packages + usrmerge
are installed.

> Isn't there potential for
> autoconf or libtool to get confused too?

Yes, there is some potential for confusion. If you program detects the path
of binaries or libraries and then hardcodes that, it may get paths wrong,
as it will probably choose the / path over the /usr one. This won't be a
problem for usrmerged systems, but it will for non-merged ones.

> Anyway, I'll test raphael's patch.

Thanks!

-- 

Saludos,
Felipe Sateler

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Wookey]

Wookey wrote:
Anyway, I'll test raphael's patch. 

OK, so building dpkg is a bit tricky becuase it FTBFS with the same
ld-linux-armhf.so.3 dpkg-shlibdeps error, but adding a -l/lib/ in the
rules file fixed it.

With the new dpkg installed, mythtv did indeed run through
dh_shlibdeps OK, although there were a lot of "dpkg-shlibdeps:
warning: tried to merge the same object ($library) twice in a symfile"

So, yes that patch seems to work (if rather too noisily). 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Marco d'Itri]

On Nov 15, Wookey  wrote:

> How is the usrmerge done? bind-mounting? hardlinks?
rename(2)

> Is dpkg-shlibdeps the only thing that is going to wrong if files stop
> having a canonical location in the system? It's a pretty major change
> having every library (and a load of binaries?) appear twice? (Or do I
> misunderstand how this is implemented?).
This has been the only significant issue so far.
Red Hat released RHEL7 with a merged /usr and I am not aware of any 
troubles.

> Like Guillem, I'd be a lot happier if files, especially libraries,
> only existed in the place they existed, and if we want to move that
> then we should move it in the packaging. Isn't there potential for
> autoconf or libtool to get confused too?
Apparently not.
We will never be able to remove the /{lib*,bin,sbin} symlinks (they are 
more or less all requires by ABIs), but sooner or later we should drop 
support for non-merged systems and just install everything in /usr.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Wookey]

On 2016-11-15 15:53 -0300, Felipe Sateler wrote:
> On Tue, 15 Nov 2016 17:22:12 + Wookey  wrote:
> > Package: dpkg
> > Version: 1.18.10
> > Severity: normal
> >
> > I built a large package (mythtv) with this recipie:
> >  git clone https://github.com/MythTV/packaging -b fixes/0.28
> >  cd packaging/deb
> >  ./build-debs.sh fixes/0.28
> >
> > This all works fine until the dh_shlibdeps when packing it up at the
> > end.
> >
> > which complains about missing dependency info for
> > /usr/lib/ld-linux-armhf.so.3
> 
> This is the same as #843073, so merging. Raphael has proposed a patch
> on that bug, but it needs more testing before it is accepted.

Right. Cheers for that. (I failed to check the dpkg bugs first because
I started filing against glibc and checked that list, then realised
part way through that this was best filed against dpkg).

How is the usrmerge done? bind-mounting? hardlinks?

Is dpkg-shlibdeps the only thing that is going to wrong if files stop
having a canonical location in the system? It's a pretty major change
having every library (and a load of binaries?) appear twice? (Or do I
misunderstand how this is implemented?).

Like Guillem, I'd be a lot happier if files, especially libraries,
only existed in the place they existed, and if we want to move that
then we should move it in the packaging. Isn't there potential for
autoconf or libtool to get confused too?

Anyway, I'll test raphael's patch. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#843073: dpkg: dpkg-shlibdeps failing due to /usr/lib/ld-linux-armhf.so.3 symlink

[Felipe Sateler]

Control: forcemerge 843073 844430

Hi,

On Tue, 15 Nov 2016 17:22:12 + Wookey  wrote:
> Package: dpkg
> Version: 1.18.10
> Severity: normal
>
> I built a large package (mythtv) with this recipie:
>  git clone https://github.com/MythTV/packaging -b fixes/0.28
>  cd packaging/deb
>  ./build-debs.sh fixes/0.28
>
> This all works fine until the dh_shlibdeps when packing it up at the
> end.
>
> which complains about missing dependency info for
> /usr/lib/ld-linux-armhf.so.3

This is the same as #843073, so merging. Raphael has proposed a patch
on that bug, but it needs more testing before it is accepted.


Saludos,
Felipe Sateler