On Fri, Jun 21, 2013 at 2:52 AM, Mathieu Malaterre <ma...@debian.org> wrote:
> # breaking a 'should' req from §8.6
> tags 712666 serious
> thanks
>
> On Fri, Jun 21, 2013 at 11:42 AM, Vincent Cheng <vincentc1...@gmail.com>
> wrote:
>> On Wed, Jun 19, 2013 at 2:28 AM, Mathieu Malaterre <ma...@debian.org> wrote:
>>> On Wed, Jun 19, 2013 at 11:21 AM, Vincent Cheng <vincentc1...@gmail.com>
>>> wrote:
>>>> On Tue, Jun 18, 2013 at 5:50 AM, Mathieu Malaterre <ma...@debian.org>
>>>> wrote:
>>>>> I would say that d/control is incomplete, it should read:
>>>>>
>>>>> Package: primus-libs
>>>>> Architecture: i386 amd64
>>>>> Depends: ${shlibs:Depends}, ${misc:Depends}, libglapi-mesa
>>>>>
>>>>> Here is what i see:
>>>>>
>>>>> $ strings /usr/lib/primus/libGL.so.1 | grep glapi
>>>>> libglapi.so.0
>>>>>
>>>>>
>>>>> Comments ?
>>>>
>>>> Why does dpkg-shlibdeps not add libglapi-mesa as a dependency / how
>>>> can I get dpkg-shlibdeps to do that? I'd much rather avoid hardcoding
>>>> dependencies if at all possible.
>>>
>>> Simply because the lib is never linked in. It is dlopen'ed:
>>>
>>> $ grep -r PRIMUS_LOAD_GLOBAL *
>>> libglfork.cpp: needed_global(dlopen(getconf(PRIMUS_LOAD_GLOBAL),
>>> RTLD_LAZY | RTLD_GLOBAL)),
>>>
>>> dpkg-shlibdeps simply read the output of readelf -d /usr/lib/bla.so.
>>> So in this case yes you have to explicitly add the Depends yourself
>>> -IMHO-. Maybe there are other way to do it, but I do not know.
>>>
>>> HTH
>>
>> After a short conversation with upstream [1], I believe that this is
>> more likely than not some sort of packaging issue with mesa. Mesa in
>> all currently supported versions of Debian is built with
>> --enable-shared-glapi, so theoretically libgl1-mesa-glx (which
>> contains mesa's libGL.so.1) should pull in libglapi-mesa
>> automatically. That's definitely the case on my current jessie/sid
>> system:
>>
>> $ apt-cache depends libgl1-mesa-glx | grep glapi
>> Depends: libglapi-mesa
>>
>> i.e. we shouldn't have to declare an explicit dependency on libglapi-mesa.
>
> libglapi-mesa only appears in wheezy, ref:
>
> http://packages.debian.org/unstable/libglapi-mesa
Ack, so primus isn't going to work on squeeze as-is. Hmmm...if you'd
still like to see bumblebee and co. backported to squeeze, I suppose
you could try using virtualgl instead. However, it's not packaged yet
(on my todo list, but you're welcome to take over if you want), and
it'd also require backporting of its dependencies (libjpeg-turbo,
which I imagine wouldn't be trivial to backport).
> Your package thus:
> 1. does not work on oldstable (squeeze), and any derivatives at that point
> 2. does not list a required dependency (what if the ABI changes ?)
> 3. any new arch added to debian (or derivatives), where mesa is built
> with --disable-shared-glapi will not work
>
> As described in the bug report upstream, this is a clear dependency
> and is a requirerment. I do not understand why you would not want to
> clarify that at debian/control level...
As far as I understand, what upstream is trying to say is that there's
simply no valid way to express primus' dependencies using
debian/control syntax. Just because libglapi-mesa exists as a package
and is installed, doesn't mean that primus will actually be
functional. As an example (provided by upstream, just paraphrasing
here), the mesa maintainers could one day stop building mesa opengl
with --enable-shared-glapi, and still provide libglapi-mesa as a
package (e.g. by building mesa OpenGL ES with --enable-shared-glapi
instead), then primus would be installable with libglapi-mesa as a
dependency, but still be broken.
Again, AFAIU upstream's argument boils down to it simply being
impossible to "clarify that at debian/control level", that just
because libglapi-mesa is installable, does not guarantee that primus
would work, so depending on libglapi-mesa serves no purpose.
As for point (2):
amonakov: "libglapi is an implementation detail of Mesa. primus does
not depend on libglapi itself (there is no documented public interface
to depend on"
So I guess that in effect, primus can break at any time, and adding a
dependency on libglapi-mesa does nothing to stop this from happening?
> I understand (1) & (3) should be very rare event. However (2) is
> pretty clear, see §8.6 Dependencies between the library and other
> packages
>
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-depends
>
> [Other packages which use a shared library (for example using
> dlopen()) should compute appropriate dependencies using these files at
> build time as well.]
A bit of a tangent, but "should" != "must".
Regards,
Vincent
(And sorry for that very long delay in between this and my last reply)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
