Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 19 Jun 2018, 06:53
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
How do you get rid of orphaned libraries?
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 4 [56 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
musher0


Joined: 04 Jan 2009
Posts: 12314
Location: Gatineau (Qc), Canada

PostPosted: Wed 24 Aug 2016, 02:21    Post subject:  

Yes that could work... to a point.

However, after doing some research, Sailor Enceladus said:
> "So some libraries and binaries are just there, in case you install something later"
If that statement is verified as true (which I suspect from my own little experience
above), it could explain the high, unreal, number of "orphaned" libs waiting to be
adopted by a program.

If that is true, would there be a corresponding program in our "packages list"?

As for me, -- if that approach is proven right -- I don't really like it. If you want a QT
program I think that you should load the QT library sfs and then install the QT
program you want. The Qt library should not be in the Puppy already if there are no
QT programs offered in the out-of-the-box Puppy. IMO, it's simpler that way.

Maybe that's the reason why Puppies are getting bigger and bigger.

Anyway, I think we have lots of testing to do before we come to any conclusion.

BFN.

_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)
Back to top
View user's profile Send private message 
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

PostPosted: Wed 24 Aug 2016, 05:42    Post subject:  

musher0 wrote:
Sailor Enceladus said:
> "So some libraries and binaries are just there, in case you install something later"
If that statement is verified as true (which I suspect from my own little experience
above), it could explain the high, unreal, number of "orphaned" libs waiting to be
adopted by a program.


he has a point.

Quote:
I don't really like it. If you want a QT
program I think that you should load the QT library sfs and then install the QT
program you want. The Qt library should not be in the Puppy already if there are no
QT programs offered in the out-of-the-box Puppy. IMO, it's simpler that way.


its not simpler-- its more streamlined. as to "which is better" i really think it depends on the amount of in-use infrastructure vs. the amount of "just in case" infrastructure.

you put roads in assuming cars will come. if you insist that cars bring their own road when they come, this is more efficient from a city-planners point of view but for a car manufacturer its a nightmare... actually this metaphor is all wrong. the point is, if qt is going to be used by many things and it adds little weight to puppy, theres a case to be made for it.

if it adds a lot of weight or isnt used by many things (or if this just-in-case philosophy is taken too far) then the simplicity of "its already there" is outweighed by the complication of "how can we get rid of it?"

qt is just one example, so it can go either way. tinycore is what you get when you keep pushing for "bare bones for everyone." theres something about "a package for a package for everything" and debian has very little in the way of orphans-- but what makes it different from tinycore is that when you install it, you have a furnished apartment. you dont have to run out to ikea and buy everything at once.

and what puppy (for most people-- i actually think bare bones is a great idea for some) does is actually find a middle ground between tiny core and debian-- it has a lot of small furnishings to explore, and isnt bare at all. its minimalist, as opposed to stripped. that could change, but for > 10 years it has stayed minimalist, while bare bones remains an option (instead of a standard.) perhaps thats a hint as to what appeals to more people. or not.

i used tiny core for quite some time, talking to robert when it was new. eventually i got tired of watching it load packages on boot, and it went from novel to tedious. its still a great idea-- its the smart fortwo of distros.

anyone going minimalist should consult the law of diminishing returns-- at a certain threshold, minimalism goes from actual simplicity to an overbearing full-time job. having tried several approaches-- mine is now to get a reliable distro, strip the unreliable and offensive parts, add whats needed, and (really above all) use a window manager that doesnt waste resources.

in puppy its jwm+rox, for me its icewm and pcmanfm. thats a simple optimization with a giant return-- few things you can do for a distro will streamline you more than that. squashfs and running in ram are quite the tools also. after the window manager, the browser is our biggest problem.
Back to top
View user's profile Send private message 
anikin

Joined: 10 May 2012
Posts: 1009

PostPosted: Wed 24 Aug 2016, 06:15    Post subject:  

musher0 wrote:
Hello all.

I'm still in lazy mode, looking for ready-made solutions.

What is the attached script worth in the context of Puppy?
From: http://www.linuxquestions.org/questions/slackware-14/slack-script-to-detect-orphaned-libraries-broken-lib-links-missing-dependencies-794133/
Retrieved: 10 minutes ago.

Is this any good for us?
Could it be adapted? Improved?

Thanks in advance.

~~~~~~~~~~
Found through DucDuckGo using the search phrase:
linux orphaned libraries NOT deborphan
Ran a couple tests on Debian Live and DebianDog Wheezy. To jump to a quick conclusion, this script is no good for me. Maybe it's good for Slackware, I don't know, but not on Debian. It treats almost every lib and binary it sees as orphaned. It shows no precision, whatsoever. This is in a stark contrast to debfoster & deborphan, the combo I normally use for remastering. Both work beautifully, not that I totally rely on their precision, no, but at least, I know what to expect of them and it goes without saying, they are very well documented and easy to use for us, little Linux neophytes.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Wed 24 Aug 2016, 08:33    Post subject:  

Dependencies can only be accurately documented at build-time. There are also some caveats for special cases, like where a program depends on another non-library binary (like man depends on groff) or uses dynamically loaded libs/plugins which constitute a 'soft' dependency.

The package manager for puppy is not able to provide this information accurately because the information is not made available during build-time, by including the info *inside* the package. External databases do not work because you can never be sure that the version of the database is the same one as was used to produce the package. Of course, this is the smae problem with using packages built elsewhere.

Resolving a dependency is not about finding the same version of a needed library -it must be have been compiled with the same options and toolchain as the original library one is trying to match. In short, unless the needed lib and the wanted binary are produced together in a unified way, you can never be sure that the library will really satisfy the dependency that the program calls for.

The situation with Slackware is only slightly better than with puppy in that the packages are sort of produced in a unified way, but dependencies must be abstracted using ldd & Co. But Slackware does not rebuild packages when the toolchain and/or dependent libs change, which means that you can't even be sure that a certain Slackware package is really compatible with the libs it *appears* to depend on.

Another thing is that 'ldd' is not really accurate.

You cannot rely on any external data about dependencies from other distros or builds.
Back to top
View user's profile Send private message 
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

PostPosted: Wed 24 Aug 2016, 10:18    Post subject:  

amigo wrote:
Another thing is that 'ldd' is not really accurate.


i was curious if something like this would come up. before i use ldd for much of anything, please let me know what ldds limitations are-- youve dropped a hint here, im only asking you expand on it if possible. certainly not a call for proof or exposition (though id read that with interest, too) Smile links welcome in lieu of more. i can search-- id like your input if possible.
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12314
Location: Gatineau (Qc), Canada

PostPosted: Wed 24 Aug 2016, 10:43    Post subject:  

I suppose none of you elegant minds care to edit my script or the slackware one to
see what's wrong or missing, and really make one of them work for the Puppy.

You'll make it to the Puippy Hall of Fame if you do, you know. Smile
This is pristine territory, except for Iguleder's account on his LibrePup.

Or are we just writing novelettes and comments in this thread, eh?
Come on people, cough up some code!!!

_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12314
Location: Gatineau (Qc), Canada

PostPosted: Wed 24 Aug 2016, 10:48    Post subject:  

anikin wrote:
musher0 wrote:
Hello all.

I'm still in lazy mode, looking for ready-made solutions.

What is the attached script worth in the context of Puppy?
From: http://www.linuxquestions.org/questions/slackware-14/slack-script-to-detect-orphaned-libraries-broken-lib-links-missing-dependencies-794133/
Retrieved: 10 minutes ago.

Is this any good for us?
Could it be adapted? Improved?

Thanks in advance.

~~~~~~~~~~
Found through DucDuckGo using the search phrase:
linux orphaned libraries NOT deborphan
Ran a couple tests on Debian Live and DebianDog Wheezy. To jump to a quick conclusion, this script is no good for me. Maybe it's good for Slackware, I don't know, but not on Debian. It treats almost every lib and binary it sees as orphaned. It shows no precision, whatsoever. This is in a stark contrast to debfoster & deborphan, the combo I normally use for remastering. Both work beautifully, not that I totally rely on their precision, no, but at least, I know what to expect of them and it goes without saying, they are very well documented and easy to use for us, little Linux neophytes.

That is great for Debian-ists, but no good for us Puppy-ists...
Back to square one I suppose.

_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)
Back to top
View user's profile Send private message 
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

PostPosted: Wed 24 Aug 2016, 11:03    Post subject:  

musher0 wrote:
edit my script or the slackware one to
see what's wrong or missing, and really make one of them work for the Puppy.


well your management style leaves some room for improvement Smile ive been watching the thread with interest, but i thought someone already tried your script. im still trying to figure out if it can work. im waiting to hear from amigo... and what about our raises?
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12314
Location: Gatineau (Qc), Canada

PostPosted: Wed 24 Aug 2016, 11:07    Post subject:  

Thank you Messrs amigo and learnhow2code.

Great tutorials, but as to action on the subject of this thread, not so much, IMO.

Ok. I'll have to get a bit un-cool, I'm afraid: I need an accurate script to determine if
there are orphaned libraries in the Puduan and then remove them safely.

Not a tutorial, a script.

Iguleder did it for his LibrePup. And his LibrePup still worked great afterwards.
So it can be done.

Many thanks in advance.

_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12314
Location: Gatineau (Qc), Canada

PostPosted: Wed 24 Aug 2016, 11:09    Post subject:  

learnhow2code wrote:
[quote="musher0"edit my script or the slackware one to
see what's wrong or missing, and really make one of them work for the Puppy.


well your management style leaves some room for improvement Smile ive been watching the thread with interest, but i thought someone already tried your script. im still trying to figure out if it can work. im waiting to hear from amigo... and what about our raises?[/quote]
~~~~~~~~~~~~
All right, funny guy! I'll look elsewhere, then.

I'm no diplomat, I'm no CEO. The Regional Co-ops Director here used to call me
"un homme de terrain", I work the field until I get results. Get used to it! Wink

learnhow2code thinks he can be a trade-unionist negotiator in a co-operative
context. He wants a raise in a context where the workers are also the bosses!

I'm really in no mood to fool with the puck, man. We have a real Puppy problem
to solve. Not your problem, not my problem, a very precise problem within Puppy.

Who's in? Who's up to the challenge?

Many thanks in advance. BFN.

_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)

Last edited by musher0 on Wed 24 Aug 2016, 11:29; edited 1 time in total
Back to top
View user's profile Send private message 
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

PostPosted: Wed 24 Aug 2016, 11:17    Post subject:  

musher0 wrote:
All right, funny guy! I'll look elsewhere


just give it time man, most of us only have two hands (some four paws, but it costs in thumbs...)
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Wed 24 Aug 2016, 15:45    Post subject:  

I'm familiar with Sasha's work. She was an avid user of src2pkg and may have prodded a feature for it out of me. She also did some interesting stuff with the Slackware init scripts so that the could use dash or ash instead of requiring bash.
tuxdev, another LQ member and regular contributor to src2pkg also did another version of no-bash init scripts. I use some code and/or ideas from both in my version of the init scripts.

Sasha completely thrashed some heavy hardware, trying to figure out how to 'compile Slackware from source'. As with Sasha's dependency script, the problem is that the package database does not include all the needed information which would/could make even rudimentary dependency-resolution possible in any reliable, accurate way.

Okay, as to ldd, anyone with an eye to system security would not use ldd to find the library symbols. The reason is that in order to find out what a program calls for, ldd executes the program and observes the verbose linking process. Running ldd on any non-trusted binary could get you in trouble. There are other tools which can be used, objdump and elf-tools are a couple. They dump the contents without executing it. And, they can provide more accurate info because they show which libs are really 'needed'. ldd shows you which libs the binary is *linked to*. Most modern forms of code linking allow for an 'as-needed' option, which only includes the symbols for libraries which are actually used by the program. Otherwise, the program will refer to symbols which it may not be using at all. Often config/Makefiles contain linking instructions which are fallacious.

Tools for slackware will certainly not work anywhere else, except for some derivatives of it -which puppy is not.

It all boils down to a few things like
a package format which includes the needed info
a package installer which can use the info *if wanted*
a database which contains the info from the packages
*a package builder* which creates packages uniform with the above -including the necessary build-time real-time, live and from-source dependency information -which must also be tweakable with human input from config files or build recipes.

If the concepts and layout used are good, then getting the info you want is really fast and simple. Generating and keeping the info in the first place is what is missing in Puppy and Slackware. Slackwareians tell you to install the whole distro before whining about dependencies. Puppy is the same thing, you get a software 'appliance' -a black box. Both are lacking all four of the above points.

Poor Sasha with her nice hardware...
Back to top
View user's profile Send private message 
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

PostPosted: Wed 24 Aug 2016, 16:18    Post subject:  

amigo wrote:
in order to find out what a program calls for, ldd executes the program and observes the verbose linking process. Running ldd on any non-trusted binary could get you in trouble. There are other tools which can be used, objdump and elf-tools are a couple. They dump the contents without executing it. And, they can provide more accurate info because they show which libs are really 'needed'.


thank you for this. this is exactly what i was trying to find out.

the reason i will never trust package data for dep info, is that every pup is different, and every package made for a pup that already includes some deps-- not others.

so when you have a package made for one pup, many (including myself) will look for packages that "seem to work" on their own pup as well.

since packaging data does not include the expected deps already native to the pup theyre made for (most things require bash, but dont list it because its known to be on most pups-- thats one example, of countless) the packaging data is potentially useless wrt any other pup. thats why id rather look at the binary-- its all we can be sure about. but now i agree with you about ldd.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Wed 24 Aug 2016, 16:28    Post subject:  

But see, even having the symbols that binary calls for doesn't mean they are the same libs which get linked -even if the version is the same, even if the toolchain is the same, even if the *explicit config options are the same.

The thing is that many sources use auto-discovery to find out if the build system has the necessary build-time and run-time objects needed to build the source. What I'm getting at, is that one library can contain symbols and functionality -because some optional external libs were present on the build system. ffmpeg is probably an extreme example.

If you try to use a binary which thinks the lib contains that optional symbol and the library you have does not contain those symbols, you have a case where an *apparently-resolved* dependency will not work.
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12314
Location: Gatineau (Qc), Canada

PostPosted: Wed 24 Aug 2016, 17:02    Post subject:  

Finally, two top minds on this! Please go on, please go on! We're listening! Smile
_________________
musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 4 [56 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1252s ][ Queries: 12 (0.0080s) ][ GZIP on ]