How do you get rid of orphaned libraries?

[musher0]

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.

[learnhow2code]

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.

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.

[anikin]

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 ... es-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.

[amigo]

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.

[learnhow2code]

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) links welcome in lieu of more. i can search-- id like your input if possible.

[musher0]

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.
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]

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 ... es-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.

[learnhow2code]

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 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?

[musher0]

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]

[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 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!

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.

[learnhow2code]

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...)

[amigo]

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...

[learnhow2code]

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.

[amigo]

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.

[musher0]

Finally, two top minds on this! Please go on, please go on! We're listening!

[learnhow2code]

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.

[anikin]

... 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 Seriously, though, I have a question: what is <puduan> - what's in that name? I must have missed some earlier discussion.

[learnhow2code]

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.

[anikin]

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

[amigo]

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.