Hi: El Lunes, 6 de octubre de 2014 14:52:54 Enrico Zini escribió: > Control: tag -1 +help > > On Fri, Feb 21, 2014 at 11:32:36PM +0100, Raúl Sánchez Siles wrote: > > Since I bumped into this, i took a look at it. Maybe you could think of > > a > > better solution but here you can find attached a patch based on dh-exec [...] > Unfortunately I don't understand what is going on here, so I can't think > of a better solution, and I am would not upload with a patch that I > don't understand. > > I'm just tagging this bug help for now. > > > Enrico
I'll try to explain how I see the issue. Just in case I fail to see
something evident.
Upstream part of libept installs libept.so.1.aptpkg4.12 This is the principal
part of libept1.4.12 package. Let's call this solib "the solib"
As a solib, and taking into account multiarch, the solib is installed at
/usr/lib/<multiarch-triplet>
After this you want that the solib is also loaded/linked with the libept
alias so you also want a link named libept.so.1.0.5.4.12. What you are doing
now is, from the debian packaging, in the libept1.4.12.links, you specify that
libept.so.1.0.5.4.12 points to libept.so.1.aptpkg4.12 (the solib)
Unfortunately this is not working because in the libept1.4.12.links file, you
expect libept.so.1.aptpkg4.12(the solib) to be located at /usr/lib which is
not true in multiarch ready package. According to the multiarch policy, the
solib is installed at /usr/lib/<multiarch-triplet> as I said above.
The patch I submitted addressed the issue using dh-exec which is smart
enough knowing what the real path for the solib is, including the multiarch
part. The path resolution happens in the package building time.
The alternative solution would be tweaking upstream build system and
creating the link from there, but I thought dh-exec approach would be
acceptable.
HTH. Regards,
--
Raúl Sánchez Siles
----->Proud Debian user<-----
Linux registered user #416098
signature.asc
Description: This is a digitally signed message part.
