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 3 of 4 [56 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

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

amigo wrote:
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.


i get what youre saying, but not where youre going with it. so answer me this: are you trying to say: "but even if you stop using ldd, and start using something more accurate and safe, you still wont get what youre trying to get, because you dont know that the binaries are NOT satisfied by some unnamed/unrequest thing that was linked as a stand-in?" because thats what i think you could be saying.

the implication of that would be "an unverifiable promise from a package system is something that could be worth more than concrete requirements that are ignored by the maintainer of a reasonably intact package-- even though in this case (because puppy packages have no such goal) it ISNT worth more, which means there is no real solution except one we have little control over.
Back to top
View user's profile Send private message 
anikin

Joined: 10 May 2012
Posts: 1009

PostPosted: Thu 25 Aug 2016, 06:16    Post subject:  

musher0 wrote:
... That is great for Debian-ists, but no good for us Puppy-ists...
Back to square one I suppose.
Puppy-ist is a person who's striving to become a Debian-ist. That's how it's defined in my book. You are not quite there yet, mon frère Smile Seriously, though, I have a question: what is <puduan> - what's in that name? I must have missed some earlier discussion.
Back to top
View user's profile Send private message 
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

PostPosted: Thu 25 Aug 2016, 07:26    Post subject:  

anikin wrote:
what is <puduan> - what's in that name?


puppy+devuan. though the "d" is interesting:

puppy devuan

i wouldve gone with pupuan, or "pup-one," though i suppose if people didnt like it youd be opening it up to some colorful phrases.
Back to top
View user's profile Send private message 
anikin

Joined: 10 May 2012
Posts: 1009

PostPosted: Thu 25 Aug 2016, 07:46    Post subject:  

Thanks for the explanation, learnhow2code. I suspected there had to be a connection with devuan ... reminds me of Papua New Guinea, though https://www.youtube.com/watch?v=wfWMv8Y1V5E
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Thu 25 Aug 2016, 09:07    Post subject:  

My Four Points should have been five. Dependency-resolution requires a proper repository which fulfills the strict needs of the package manager.

There simply is no way to accurately predict whether any 'foreign-made' binary object(lib or executable) will be 100% compatible with another foreign or locally-produced object.

So, the software *delivery* system also has to be a part of the Big Picture. Each of the Five Points could be elaborated -file-naming and versioning conventions, directory layout, structure and nature of the database and of course what data is needed/wanted --all these have to be taken into consideration. There are also actions to be taken when installing/upgrading/uninstalling packages -usually some sort of script, or the package database contains a list of options which cause the package manager to carry out tasks other than installing files -like creating users,groups or whatever.

For years I tried to coax src2pkg into creating an enhanced database for use with slackware packages. However, Slackware contains a couple of packages which absolutely kill any chance of sane and complete dependency info. Finally, I created my own package format (tpkg) and the tools for handling the packages. It was a snap to get src2pkg making packages with *lots* of info and overcome the drawbacks of Slackware's packaging system.

After 2-3 years I started designing a new package format which is more capable and faster.

Using the tpkg tools, answering the OP's question would be pretty easy, but this aspect of package management requires a Blacklist/Whitelist approach -there are packages which do not depend on any other package and yet are indispensable. This one of the things where the new (tpm) package format is improved.
Back to top
View user's profile Send private message 
musher0


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

PostPosted: Thu 25 Aug 2016, 13:30    Post subject:  

anikin wrote:
Thanks for the explanation, learnhow2code. I suspected there had to be a connection with devuan ... reminds me of Papua New Guinea, though https://www.youtube.com/watch?v=wfWMv8Y1V5E
No, no, no, it should be reminding you of the beautiful city of Padua, in Italy. Laughing
_________________
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: Thu 25 Aug 2016, 14:00    Post subject:  

one of the ways to reduce orphan libraries is to not have them included in the first place. this requires a change of tack.

i was really thinking something more practical, but even if you renamed "orphan libraries" to "bastard libraries" people might get rid of them faster.

"try my distro!"
"how many bastard libraries does it have?"
"um, i dont know!"
"..."

mine is a complete bastard os, so this doesnt always work.
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 1067

PostPosted: Thu 25 Aug 2016, 14:03    Post subject:  

If a different library is linked then couldn't one look for symbolic links? Also someone has mentioned the need for a consistent directory strucure but a binary looks in typical directories for suitable lbraries. One dosn't need to search the entire file system.
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1512

PostPosted: Thu 25 Aug 2016, 15:40    Post subject:  

I know that orphan program musher0 linked to from linuxquestions showed a lot of false positives. It told me /usr/bin/7za is an orphan, for instance, and I USE it in XArchive to extract 7z files! lol. I think woof-ce had something similar, I tried the "remove unused dependencies" option in it, and it just blew everything up. If the woof-ce version doesn't work, I'd say that's a pretty safe bet that only manual removal of things by being a complete linux genius and knowing exactly what uses what is the answer. Possibly only 01micko is on this level, or close to it, with his constant refinement of slacko since 5.3, but things are always changing too, so it's a constant battle of understanding everything there is to know about each of the 11000-17000 files that go into the puppy.sfs file, and how/if they relate to each other, or to anything; I think. Might have to google every file.
Back to top
View user's profile Send private message 
musher0


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

PostPosted: Thu 25 Aug 2016, 18:32    Post subject:  

And then every one in this thread paused, sat down in the lotus position, took deep
breaths and spent the day meditating on Sailor's wise paragraph above.

(My sentence may be fanciful, but it is not a mockery at all.)

_________________
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: Thu 25 Aug 2016, 20:07    Post subject:  

well, i tried my hand at woof-ce (legacy) today.

i ran a lot of scripts.
i ran a gui.
i downloaded stuff.
i selected options.
i made folders.
i watched things run.
it didnt work.
so i had a look at the script that probably does all the real work: the builddistro-Z script.

alrighty!

so when i work on puppy things, i think i wont be using woof-ce. perhaps rationalize is so much cleaner, but i like bash-- i dont like it THAT MUCH. i will try to find another way.

at least i tried. i think i can say that approach is NOT what i want. and what DOES this have to do with this thread, anyway? simple: whatever version of mushers issue im going to "solve" or not, its probably going to be solved in a way that is completely different/incompatible anyway. sorry, musher-- it cant be done. (now thats said, someone will prove it can-- thats great!)
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1512

PostPosted: Thu 25 Aug 2016, 20:20    Post subject:  

learnhow2code wrote:
(now thats said, someone will prove it can-- thats great!)

lol but you jinxed it by adding this part, now we are doomed forever Crying or Very sad Laughing (If this really is bad at all)
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 1067

PostPosted: Thu 25 Aug 2016, 20:51    Post subject:  

Sailor Enceladus wrote:
I know that orphan program musher0 linked to from linuxquestions showed a lot of false positives. It told me /usr/bin/7za is an orphan, for instance, and I USE it in XArchive to extract 7z files! lol. I think woof-ce had something similar, I tried the "remove unused dependencies" option in it, and it
just blew everything up. If the woof-ce version doesn't work, I'd say that's a pretty safe bet that only manual removal of things by being a complete linux genius and knowing exactly what uses what is the answer. Possibly only 01micko is on this level, or close to it, with his constant refinement of slacko since 5.3, but things are always changing too, so it's a constant battle of understanding everything there is to know about each of the 11000-17000 files that go into the puppy.sfs file, and how/if they relate to each other, or to anything; I think. Might have to google every file.


Amigo mentioned a white/black list. Perhaps we could build one by running strace on some programs we like. Maybe start with some of the programs in the puppylinux menu.
Back to top
View user's profile Send private message 
learnhow2code

Joined: 12 Jun 2016
Posts: 1015

PostPosted: Thu 25 Aug 2016, 20:53    Post subject:  

s243a wrote:
Amigo mentioned a white/black list. Perhaps we could build one by running strace on some programs we like.


that was quicker than i thought it would be.
Back to top
View user's profile Send private message 
TeX Dog

Joined: 06 Jul 2016
Posts: 341

PostPosted: Mon 29 Aug 2016, 18:09    Post subject:  

A billion lines of code ago (1BC) we used access bit in the filesystem and did not preload libs. After a complete run of the test cases only those files that where 'accessed' where bundled and shipped. Only caused problems for a few clients which our test cases where weak.
My understanding all that low level file access control are currently not compiled in since it doesn't play nice with layer file systems, like puppy which still can't be 'truly' installed.
It was also used for the ordering of laying out files in the filesystem, when seek time was poor and that mattered. Knoppix was the last live distro to use such a idea, that is why a DVD sized anti-puppy colossus loads so quickly. Wish he will share HIS build system.

just looking around for more modern ideas
using ps grab the process ids, the call command pmap to show loaded libs pipe that those to file, sort removing dups to get all used up to that point (guess starting all apps you normally use)
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 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.0715s ][ Queries: 12 (0.0063s) ][ GZIP on ]