Page 3 of 3

Re: Resolving Non-Slackware Dependencies

Posted: 10 Oct 2015, 03:59
by francois
Is it possible to automate some of the procedures, like do you want default choice ask the way?
And what was wrong with my last trial? Have I done something wrong according to your expertise? How do I reset /pak anew without having to replace all files? Is my recap of your procedure on first page is exact?

Re: Resolving Non-Slackware Dependencies

Posted: 10 Oct 2015, 23:21
by Bogomips
francois wrote:And what was wrong with my last trial? Have I done something wrong according to your expertise? ... Is my recap of your procedure on first page is exact?
Can't tell, but seems like you have corrupted awk_distro file.
francois wrote:Is removing all the files and folder other than the four above mentioned files between runs will be enough in addition to:

Code: Select all

root@porteus:~/pak# source pakfuncs.sh
to reuse the resolver?
Once you are clean, quite the contrary. Just start a new terminal/tab.
francois wrote:How do I reset /pak anew without having to replace all files?
Am keeping permanent copy of 'pak' directory on real file system and running like so:

Code: Select all

cp -a p10/Por/PakOrg/apak .
cd apak
source ../p10/Por/pakfuncs.sh
pakorg libsystemd
At end of run if haven't made mess of things, updating thus:

Code: Select all

cp -au apak p10/Por/PakOrg
Start from scratch with a clean slate.Your download rate is multiple of mine. Here we are looking at most a 100 text files of about 20K each=100x20K=2000k=2 MB. Downloaded in a couple of seconds! After all, quite a bit of computing is about speed through superfluousness. Doing things needlessly in order to get the job done quicker in RL. :wink:
francois wrote:Is it possible to automate some of the procedures, like do you want default choice ask the way?
Unfortunately this is an intelligence driven procedure. Just replaces what you would do manually if going through pkgs.org. :wall:

Objections to Automation
  • –°hange of package name. If name does not match it could be a devel/test package. Therefore filtered out. Need to check out package by browsing. Automation might mean not remaining in same distro, when no need to change.
  • Change to something fundamental like gclibs or gcclibs or similar by going to too low a level of dependency, resultant module could crash the whole system!
Files are all there in first post. Just follow each setup step carefully. Try out the building-blocks approach as suggested in 4(b) of previous post, and see how you go.


P.S. @francois please define bnsdr

Re: Resolving Non-Slackware Dependencies

Posted: 22 Apr 2017, 12:36
by n0ctilucient
Is "depfinder" (w/ python support) a reliable means of resolving dependencies?

Re: Resolving Non-Slackware Dependencies

Posted: 22 Apr 2017, 16:45
by Bogomips
Wekcime to Porteus.

Code: Select all

root@porteus:/home/guest# usm -i depfinder
Package:    (27 K) [not installed]
depfinder: depfinder (finds dependencies of Slackware packages)
depfinder:
depfinder: depfinder is a tool that finds the dependencies of Slackware
depfinder: packages and outputs them in a comma separated list, in stdout or a
depfinder: .dep file. depfinder is very fast at calculating dependencies; the
depfinder: speed difference mainly comes from the C++ code that is used to find
depfinder: in which package each individual library is included. That C++ code is
depfinder: 'borrowed' (as in blatanly ripped) from Nigel Bosch's zpm code.
depfinder: depfinder also has support for running multiple jobs which makes it a
depfinder: *lot* faster on PCs with multiple CPUs/cores.
depfinder:
:)

Sat Apr 22 19:30:32 UTC 2017
P.S. For Slackware dependency there is always USM. ;) USM does not just output a list, but downloads the list. However there are times when USM is on the blink, and suppose in desperation one can turn to depfinder. 8)
  • USM on the blink

    Code: Select all

    root@porteus:/home/guest# usm -g depfinder  
     The following items were found.
     Choose an number to confirm. 
     ctrl+c to quit
    
    1) depfinder-1.4.1-x86_64-1gv.txz
    #? 1
    
    Processing:   depfinder-1.4.1-x86_64-1gv.txz 
    Ignored libraries: 
    
    Libraries required:  3
    Libraries found in system: 3
    Libraries to resolve: 0
    
     The following packages are required. 
    depfinder-1.4.1-x86_64-1gv.txz [] [not installed]
    
    Total size: 0 KB
    
  • Manual download

    Code: Select all

    root@porteus:/home/guest# txz2xzm  tmp64/depfinder-1.4.4-x86_64-1gv.txz
    root@porteus:/home/guest# activate  tmp64/depfinder-1.4.4-x86_64-1gv.xzm
    EXAMPLE
    guest@porteus:~$ depfinder  tmp64/conky-1.10.6-x86_64-1ponce.txz
    aaa_elflibs,aaa_elflibs|bzip2,aaa_elflibs|curl,aaa_elflibs|glib2,aaa_elflibs|libpng,aaa_elflibs|libssh2,aaa_elflibs|openldap-client,aaa_elflibs|xz,aaa_elflibs|zlib,cairo,cyrus-sasl,fontconfig,freetype,harfbuzz,imlib2,libICE,libSM,libX11,libXau,libXdamage,libXdmcp,libXext,libXfixes,libXft,libXinerama,libXrender,libXxf86vm,libdrm,libxcb|libxcb,libxml2,libxshmfence,lua,mesa,openssl,pixman,tolua++,util-linux
    
P.P.S. Having read the man page, looks like could complement USM nicely in the python arena. Another thing that springs to mind with the python switch is that the search could be extended to python dependencies of non Slackware packages, perhaps. :Search: