Re: dpkg-shlibdeps question when creating Debian packages
ah yes of course. Thank you. On Sun, Sep 15, 2013 at 12:17 AM, Steve Langasek wrote: > On Sun, Sep 15, 2013 at 12:07:17AM -0500, Pedro DeKeratry wrote: > > I received the following warnings when building with dpkg-buildpackage > > > dpkg-shlibdeps: warning: symbol pthread_sigmask used by > > debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries > > dpkg-shlibdeps: warning: symbol pthread_join used by > > debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries > > dpkg-shlibdeps: warning: symbol pthread_create used by > > debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries > > > My understanding is that pthread is in libc6 which is listed as a > > dependency in my package. Any pointers? > > You're correct that it's part of the libc6 package. But that's the > *package* dependency; this warning is about a missing *ELF* dependency. > The > library uses symbols from libpthread but does not link to it. This is a > bug, even when it doesn't cause any difference to the package dependencies. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developerhttp://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org >
Re: dpkg-shlibdeps question when creating Debian packages
On Sun, Sep 15, 2013 at 12:07:17AM -0500, Pedro DeKeratry wrote: > I received the following warnings when building with dpkg-buildpackage > dpkg-shlibdeps: warning: symbol pthread_sigmask used by > debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries > dpkg-shlibdeps: warning: symbol pthread_join used by > debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries > dpkg-shlibdeps: warning: symbol pthread_create used by > debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries > My understanding is that pthread is in libc6 which is listed as a > dependency in my package. Any pointers? You're correct that it's part of the libc6 package. But that's the *package* dependency; this warning is about a missing *ELF* dependency. The library uses symbols from libpthread but does not link to it. This is a bug, even when it doesn't cause any difference to the package dependencies. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
dpkg-shlibdeps question when creating Debian packages
I received the following warnings when building with dpkg-buildpackage dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol pthread_join used by debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries dpkg-shlibdeps: warning: symbol pthread_create used by debian/libyrp/usr/lib/libyrp.so.2.0.0 found in none of the libraries My understanding is that pthread is in libc6 which is listed as a dependency in my package. Any pointers?
Re: dpkg-shlibdeps question
On Mon, 04 May 2009 19:07:18 +0200, Raphael Hertzog wrote: On Fri, 01 May 2009, Jiří Paleček wrote: should almost never happen (except diversion) and the result when it happens is Should I read it as "the only legal situation where it returns multiple packages are diversions (the rest are errors)" or "the majority of situations ... are diversions", ie. does it make sense to return multiple packages in the absence of diversions? dpkg -S can return multiple packages for directories too since they can be shared by many packages but in the case of real files AFAIK it can only happen with diversions. Ok. Thanks. Yes, but I think this is unattainable. Especially when doing transitions, you're not likely to have both packages in sync. I don't see why it would be so difficult. Diverting a file means that you have a drop-in replacement and I don't see why you couldn't provide dependencies that are compatible (even if not exactly the same). Yes, you can make it compatible (although I'm not sure what exactly you mean by "compatible"). Or maybe even the same, but when things change, it has to be maintained, which doesn't happen automatically. I just wanted to know if it would be OK for dpkg-shlibdeps to use only one package for a library (eg. in case of diversions, use dpkg-divert to find the right one) and fail in case of ambiguity. What is the right one, the non-diverted one ? I'd say so. If the purpose of dpkg-shlibs is to translate shared object dependencies as viewed by ld.so into package dependencies for dpkg, it seems to me the correct package(s) to depend on is the one that provides the binary that was used for the build (let's put aside the situations when no package contains the library used, eg. it was provided by the user who overwrote the file from the package). Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Fri, 01 May 2009, Jiří Paleček wrote: >> should >> almost never happen (except diversion) and the result when it happens is > > Should I read it as "the only legal situation where it returns multiple > packages are diversions (the rest are errors)" or "the majority of > situations ... are diversions", ie. does it make sense to return multiple > packages in the absence of diversions? dpkg -S can return multiple packages for directories too since they can be shared by many packages but in the case of real files AFAIK it can only happen with diversions. > Yes, but I think this is unattainable. Especially when doing transitions, > you're not likely to have both packages in sync. I don't see why it would be so difficult. Diverting a file means that you have a drop-in replacement and I don't see why you couldn't provide dependencies that are compatible (even if not exactly the same). > I just wanted to know if it would be OK for dpkg-shlibdeps to use only > one package for a library (eg. in case of diversions, use dpkg-divert to > find the right one) and fail in case of ambiguity. What is the right one, the non-diverted one ? I think it would be ok for dpkg-shlibdeps to choose the right package based on some clearly-documented criteria. I don't think that failing is a good idea. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Thu, 30 Apr 2009 17:00:12 +0200, Raphael Hertzog wrote: On Thu, 30 Apr 2009, Jiří Paleček wrote: Yes, but even then, libGL.so.1 (the one used for building a package) is only mentioned in one symbol file, namely the one from nvidia-glx, isn't it (let's put aside the package doesn't feature a symbol file)? Why should the libgl1-mesa-glx symbol file, if it existed, be taken into account? We could maybe help you if you told us to what part of the code you refer when you say that a single library can be mentioned in two different symbols files ? The code is what it is for many reasons including the fact that dpkg -S can return multiple packages for a single lib file. In practice, it Exactly, that's the thing I'm referring to. should almost never happen (except diversion) and the result when it happens is Should I read it as "the only legal situation where it returns multiple packages are diversions (the rest are errors)" or "the majority of situations ... are diversions", ie. does it make sense to return multiple packages in the absence of diversions? not specified (in the doc at least). In practice you might get a mix of both dependencies and to avoid any problem the packaging of the diverting library should simply stay compatible to the one of the official library (i.e. generate the same dependencies). Yes, but I think this is unattainable. Especially when doing transitions, you're not likely to have both packages in sync. I just wanted to know if it would be OK for dpkg-shlibdeps to use only one package for a library (eg. in case of diversions, use dpkg-divert to find the right one) and fail in case of ambiguity. Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Thu, 30 Apr 2009, Jiří Paleček wrote: > Yes, but even then, libGL.so.1 (the one used for building a package) is > only mentioned in one symbol file, namely the one from nvidia-glx, isn't > it (let's put aside the package doesn't feature a symbol file)? Why > should the libgl1-mesa-glx symbol file, if it existed, be taken into > account? We could maybe help you if you told us to what part of the code you refer when you say that a single library can be mentioned in two different symbols files ? The code is what it is for many reasons including the fact that dpkg -S can return multiple packages for a single lib file. In practice, it should almost never happen (except diversion) and the result when it happens is not specified (in the doc at least). In practice you might get a mix of both dependencies and to avoid any problem the packaging of the diverting library should simply stay compatible to the one of the official library (i.e. generate the same dependencies). Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Wed, 29 Apr 2009 19:40:12 +0200, Josselin Mouette wrote: Le mercredi 29 avril 2009 à 18:51 +0200, Jiří Paleček a écrit : I've hacked a little into dpkg-shlibdeps and while doing this, I've found that the code makes allowance for a single library being mentioned in two different symbol files. I'd like to ask if (and when) can such situation actually arise. My first guess would be nvidia-glx and its diversion of libGL.so.1. Yes, but even then, libGL.so.1 (the one used for building a package) is only mentioned in one symbol file, namely the one from nvidia-glx, isn't it (let's put aside the package doesn't feature a symbol file)? Why should the libgl1-mesa-glx symbol file, if it existed, be taken into account? Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
Le mercredi 29 avril 2009 à 18:51 +0200, Jiří Paleček a écrit : > I've hacked a little into dpkg-shlibdeps and while doing this, I've found > that the code makes allowance for a single library being mentioned in two > different symbol files. I'd like to ask if (and when) can such situation > actually arise. My first guess would be nvidia-glx and its diversion of libGL.so.1. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
dpkg-shlibdeps question
Hello, I've hacked a little into dpkg-shlibdeps and while doing this, I've found that the code makes allowance for a single library being mentioned in two different symbol files. I'd like to ask if (and when) can such situation actually arise. Regards Jiri Palecek -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
