On 15 November 2016 at 18:17, Wookey <woo...@wookware.org> wrote:
> On 2016-11-15 15:53 -0300, Felipe Sateler wrote:
>> On Tue, 15 Nov 2016 17:22:12 +0000 Wookey <woo...@wookware.org> 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
