LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   [ANN] sbbdep 0.1.1 release, new feature --xdl (http://www.linuxquestions.org/questions/slackware-14/%5Bann%5D-sbbdep-0-1-1-release-new-feature-xdl-4175434251/)

a4z 10-26-2012 03:03 PM

[ANN] sbbdep 0.1.1 release, new feature --xdl
 
1 Attachment(s)
I just pushed sbbdep 0.1.1 slk bundle to the download section on bitbuckzt.

https://bitbucket.org/a4z/sbbdep_slk...k-0.1.1.tar.gz
please take the build instructions from here
https://bitbucket.org/a4z/sbbdep_slk/overview


beside some minor internal fixes and improvements
and that the root dir of the sbbdep_slk is now versioned (extract = sbbdep_slk-0.1.1 )
I added the --xdl option.
xdl stands for something like explaind dynamic linked
instiration for this came from this thread
http://www.linuxquestions.org/questi...nf-4175433261/

and I thought it is a nice possibility to showcase whatfor sbbdep can be used (there is of course more possible)

(Eric, I adopted your build script to the new version, and attach it so you can simply use it, hope that is ok.)


no long description, here what is does.

Code:

./sbbdep --nosync --xdl /usr/lib64/libGLU.so
Absolute path: /usr/lib64/libGLU.so.1.3.08004
 from package:mesa-8.0.4-x86_64-1
link name is: libGLU.so.1
dependencies from own package:
  /usr/lib64/libGL.so.1.2 : mesa-8.0.4-x86_64-1
dependencies from others:
  /lib64/libc-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien
  /lib64/libm-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien
  /usr/lib64/libgcc_s.so.1 : gcc-4.7.1_multilib-x86_64-1alien,  aaa_elflibs-14.0-x86_64-4
  /usr/lib64/libstdc++.so.6.0.17 : gcc-g++-4.7.1_multilib-x86_64-1alien,  cxxlibs-6.0.17-x86_64-1

works also with binaries

Code:

./sbbdep --nosync --xdl ./sbbdep           
Absolute path: /home/slk140/a4work/sbbdep/buildDebug/bin/sbbdep
/home/slk140/a4work/sbbdep/buildDebug/bin/sbbdep not in a known package
dependencies from others:
  /lib64/libc-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien
  /lib64/libm-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien
  /lib64/libpthread-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien
  /usr/lib64/libelf.so.0.8.13 : libelf-0.8.13-x86_64-2,  aaa_elflibs-14.0-x86_64-4
  /usr/lib64/libgcc_s.so.1 : gcc-4.7.1_multilib-x86_64-1alien,  aaa_elflibs-14.0-x86_64-4
  /usr/lib64/libgomp.so.1.0.0 : gcc-4.7.1_multilib-x86_64-1alien
  /usr/lib64/libmagic.so.1.0.0 : file-5.11-x86_64-1
  /usr/lib64/libstdc++.so.6.0.17 : gcc-g++-4.7.1_multilib-x86_64-1alien,  cxxlibs-6.0.17-x86_64-1

and something more difficult (timed to see the speed on a notebook with slow hd)

Code:

time ./sbbdep --nosync --xdl /usr/lib64/libnss3.so
Absolute path: /usr/lib64/libnss3.so
 from package:mozilla-nss-3.13.5-x86_64-3
link name is: libnss3.so
  also provided from:
  seamonkey-2.12.1-x86_64-1:/usr/lib64/seamonkey-2.12.1/libnss3.so
  seamonkey-solibs-2.12.1-x86_64-1:/usr/lib64/seamonkey-2.12.1/libnss3.so
dependencies from own package:
  /usr/lib64/libnspr4.so : mozilla-nss-3.13.5-x86_64-3
  /usr/lib64/libnssutil3.so : mozilla-nss-3.13.5-x86_64-3
  /usr/lib64/libplc4.so : mozilla-nss-3.13.5-x86_64-3
  /usr/lib64/libplds4.so : mozilla-nss-3.13.5-x86_64-3
dependencies in own and others:
  /usr/lib64/seamonkey-2.12.1/libnspr4.so : seamonkey-2.12.1-x86_64-1,  seamonkey-solibs-2.12.1-x86_64-1
  /usr/lib64/seamonkey-2.12.1/libnssutil3.so : seamonkey-2.12.1-x86_64-1,  seamonkey-solibs-2.12.1-x86_64-1
  /usr/lib64/seamonkey-2.12.1/libplc4.so : seamonkey-2.12.1-x86_64-1,  seamonkey-solibs-2.12.1-x86_64-1
  /usr/lib64/seamonkey-2.12.1/libplds4.so : seamonkey-2.12.1-x86_64-1,  seamonkey-solibs-2.12.1-x86_64-1
dependencies from others:
  /lib64/libc-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien
  /lib64/libdl-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien
  /lib64/libpthread-2.15.so : glibc-solibs-2.15_multilib-x86_64-7alien,  glibc-2.15_multilib-x86_64-7alien

real    0m0.105s
user    0m0.090s
sys    0m0.015s

to be fair, note that I use the --nosync option cause I know that my cache is in sync (no install/update) what is the usual usecase.
time of sync depends also on a lot of things, mostly disk speed, but usually it is also a fast operation (if nothing is to do and it is done the 2nd time so all is in the diskcache (or on a ssd the first time) < 1s, first time on hd depends totally on the disk and what is to do so there is no average time)


feel free to make problem reports and feature requests either on the bitbucket issue tracker or directly here

enjoy

Alien Bob 10-26-2012 03:55 PM

I upgraded the Slackware 14.0 packages in my repository to the new version: http://slackware.com/~alien/slackbuilds/sbbdep/

Eric

SeRi@lDiE 10-26-2012 06:07 PM

Thank you guys!

escaflown 10-26-2012 09:08 PM

Thanks!

mlangdn 10-27-2012 04:51 AM

Thanks from me as well! :)

Didier Spaier 10-27-2012 10:55 AM

Feature request
 
Thanks a4z for the program and Eric for the packages, sbbdep works pretty well.

In addition, I wish it could tell more generally (i.e., not only for binary/library files) which package(s) or installation script(s) ships a specific file (for instance a data file or a text file or directory intended for configuration or documentation purpose).

Granted, 'grep <part/of/path/to/the/file> /var/log/{packages,scripts}/*' gives the answer but I am a bit lazy sometimes and it could be handy to use the same command for that.

Maybe you could make the program act differently, taking in account the file type as reported by the 'file' command, or simply add an option for this kind of query? I guess you don't need my advises to implement such a feature anyway ;)

a4z 10-27-2012 01:44 PM

Quote:

Originally Posted by Didier Spaier (Post 4816233)
Thanks a4z for the program and Eric for the packages, sbbdep works pretty well.

In addition, I wish it could tell more generally (i.e., not only for binary/library files) which package(s) or installation script(s) ships a specific file (for instance a data file or a text file or directory intended for configuration or documentation purpose).

Granted, 'grep <part/of/path/to/the/file> /var/log/{packages,scripts}/*' gives the answer but I am a bit lazy sometimes and it could be handy to use the same command for that.

Maybe you could make the program act differently, taking in account the file type as reported by the 'file' command, or simply add an option for this kind of query? I guess you don't need my advises to implement such a feature anyway ;)


make sense
and thinking about possible ways of an implementation pop up some interesting aspects.

but only if QUERY arg is an existing regular file, will not work for folders
cause for example /usr would produce every package as result and makes no sense
and sbbdep can also be used with a $DESTDIR argument to produce dependencies info

for example today I installed unrar from sbo and using /tmp/SBo/package-unrar as an argument produces already and result

./sbbdep --nosync /tmp/SBo/package-unrar
aaa_elflibs >= 14.0 | gcc >= 4.7.1_multilib
cxxlibs >= 6.0.17 | gcc-g++ >= 4.7.1_multilib
glibc >= 2.15_multilib | glibc-solibs >= 2.15_multilib

or short version
/sbbdep --nosync -s /tmp/SBo/package-unrar
aaa_elflibs | gcc, cxxlibs | gcc-g++, glibc | glibc-solibs

so folder names would conflict in functionality and/or require to much filtering that could never be done in an satisfying way.
but
./sbbdep /some/valid/file
could tell in which package(s) file is, or that it is not in a package, if it is not a dyn linked or a package.
that makes somehow sense and is interesting to implement.
to find out if a file has been created by an install script is currently not possible for me but links will be resolved anyway


All times are GMT -5. The time now is 06:41 PM.