<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 9:40 AM, Christian Ehrhardt <span dir="ltr"><<a href="mailto:christian.ehrhardt@canonical.com" target="_blank">christian.ehrhardt@canonical.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><b>TL;DR:</b></div><div>How to correctly package a source creating libraries with individual ABI's bumped separately but that depend on each other and due to that ending up in mixed versions in the executable after ld.so mapped in dependencies?</div><div>I'm reaching out to you as this is a case I have no experience with.<br></div><div>I've thought and discussed on several solutions but I'm sure on none of them yet.</div><div><ul><li>Compat packages with symlinks to the new .so version as it has ABI backward compat symbols<br></li><li>Hard inserting the major version (currently 16.11) into every library version e.g. making the new a librte_eal.so.16.11.3<br></li><li>Some magic combination of breaks/conflicts/replaces that prevents the error window (lib updated, but not consumers) to occur</li><li>Others according to your guidance</li></ul></div></blockquote></div><div class="gmail_extra"><br></div>I analyzing the compat package approach of above (see the original mail about some details on the DPDK ABI compat model).</div><div class="gmail_extra">That seemed to be the approach being the lowest hanging fruit (a.k.a not revamping big chunks of upstream code).</div><div class="gmail_extra"><br></div><div class="gmail_extra">To get more ideas how to package that I was checking the archive for other packages with similar cases.</div><div class="gmail_extra">I found several like libcurl, libhwloc and libOSMesa to have symlinks from older sonames.</div><div class="gmail_extra"><div class="gmail_extra">Of those libhwloc appeared to be most similar to our case:</div><div class="gmail_extra"> libhwloc.so.0 -> libhwloc.so.5<br></div><div class="gmail_extra"> libhwloc.so.1 -> libhwloc.so.5</div><div class="gmail_extra"> libhwloc.so.2 -> libhwloc.so.5</div><div class="gmail_extra"> libhwloc.so.4 -> libhwloc.so.5</div><div class="gmail_extra"><br></div><div class="gmail_extra">I was studying the packaging of all those and found that in their cases the dependencies where non versioned.</div><div class="gmail_extra">Therefore those packages implemented this compat with symlinks to the new soname and as "provides" field for the old named package.</div><div><br></div><div>But according to [1] "... If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied ... "</div><div>Thereby for our case this will likely not work - I confirmed that in an experimental build.</div><div><br></div><div>From there the next step was to create explicit (and versioned) packages to hold the symlink to the ABI compatible new version.</div><div>I implemented that and it works great for all combinations of old/new library and library-consumers, see [2] (this thread also holds more on why just provides fields fail).</div><div>The change itself is out for review [3] and discussion on deb_dpdk.</div><div><br></div><div>So I have a solution that works, but wanted to hereby post it to ubuntu-devel before I upload to get an early nack if it has an hidden fault.</div><div><br></div><div><div>[1] - <a href="https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual">https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual</a></div></div><div>[2] - <a href="https://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/Week-of-Mon-20170206/000011.html">https://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/Week-of-Mon-20170206/000011.html</a></div><div>[3] - <a href="https://gerrit.fd.io/r/#/c/5060/">https://gerrit.fd.io/r/#/c/5060/</a></div><div><br></div>-- <br><div class="gmail-m_5815539432197067537gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8px">Christian Ehrhardt</span><div style="color:rgb(136,136,136);font-size:12.8px">Software Engineer, Ubuntu Server</div><div style="color:rgb(136,136,136);font-size:12.8px">Canonical Ltd</div></div></div></div></div> </div></div>