Well compared to Puppy`s method of dependency tracking. I think it`s left up to the package builder.
Since when don`t dependency tree files work well? Is there a better way to include all the files needed?
Well... There`s always static building of apps. I guess, but it isn`t a favored method for obvious reasons.

Tiny Core is a modified legacy setup, but that was the easiest way to make use of the existing packages.
To really fix Linux small changes or even bigger ones have proven insufficient. Real change is needed.
I`ll have to take a look and see if there`s an ongoing discussion about directions that Tiny Core might take.

Long interesting thread. Have any conclusions been made? And decisions from this thread will be made?

Currently end users have no way to tell if a pet will/would/could work on their puppies due to the vast ammount of versatility puppies provide (basically a toy to play with) and most likely yes, with modifications/upgrades or even regresions.

In order for a pet to work it's needing to be based off bary's branches without tweaks/modifications/tunning (almost the most basic set up) though when he upgrades key stuff on his setup, all pets depending on his upgrades break, as shown by posts/experience.

Key components of the system updated leads to broken/needing to upgrade apps/pets depending on those key components. Dependencies here and there (normal in any OS, not what's being discussed anyway [let's not get into that either]) but my point was that pets work if made with the main branches in mind, without tweaks or modifications, for the basic lines distributed (barry's).

..Now I get why he call his distros puppies...he's the top dog of the pack

if it were a team decision I'd change my "No, but the PET format should be standardized/stricter." to "Yes, without backwards compatibility." but's it's up to barry's actually as far as his puppies are concerned.

my two cents
Aaaaaaaaitch ty! (tags)
PS: I'd love to have this thread as a txt/htm/pdf or all the post in a single page view for offline reading. Great ideas in here.Last edited by anewuser on Mon 12 Mar 2012, 17:27; edited 4 times in total

Long interesting thread. Have any conclusions been made? And decisions from this thread will be made?

Currently end users have no way to tell if a pet will/would/could work on their pets due to the vast ammount of versatility puppies provide (basically a toy to play with) and most likely yes, with modifications/upgrades or even regresions.

In order for a pet to work it's needing to be based off bary's branches without tweaks/modifications/tunning (almost the most basic set up) though when he upgrades key stuff on his setup, all pets depending on his upgrades break, as shown by posts/experience.

Key components of the system updated leads to broken/needing to upgrade apps/pets depending on those key components. Dependencies here and there (normal in any OS, not what's being discussed anyway [let's not get into that either]) but my point was that pets work if made with the main branches in mind, without tweaks or modifications, for the basic lines distributed (barry's).

..Now I get why he call his distros puppies...he's the top dog of the pack
if it were a team decision I'd change my "No, but the PET format should be standardized/stricter." to "Yes, without backwards compatibility." but's it's up to barry's actually as far as his puppies are concerned.

Well compared to Puppy`s method of dependency tracking. I think it`s left up to the package builder.
Since when don`t dependency tree files work well? Is there a better way to include all the files needed?

well..that's easy. It doesn't work well when there's some dep name change and your OS won't boot.

Right...the package builder determines what the deps are; so that kindof rules out woof, doesn't it ? Every flavor would have to have it's own unique and maintained database, which sounds boring to me, when I can tap into a universe of packages elsewhere.

But again... Static compilation does make the app. work without problems with what`s included.

..only in theory. How do you know what the right dependencies are to include in the static package? We live in a dynamic world, where all the components are continually shifting...unless you want to include all the xlibs, etc., for every package..and even then I'm not sure. What about the kernel, the chain, etc. Also, don't forget to include everything needed for every brand of computer in your static package.

jpeps; I kinda covered all of that... Only what`s in the compile can be vouched for. And yes, I commented earlier about the difficulty of finding the correct lib. for a build.

It`s a twisted mess only made worse by poor utilization of the proper build methods. In the case of Puppy it`s almost to the point all apps. need to be built with Puppy.
But I think verified add-on lib. SFS files could help shore up the dependency mess. Then package builders have a more solid base, reducing the size of static builds.Last edited by sunburnt on Fri 16 Mar 2012, 15:02; edited 1 time in total

Yep... All part of what`s known as dependency hell, and I don`t see any method that solves it.

But again... Static compilation does make the app. work without problems with what`s included.
There`s still dependencies but fewer of them. I`ve had good luck with large static apps. in Puppy.

In most cases, the static compile is the best way to go. You can make a script that flips in and out different versions of libraries. For some programs where the compiled version is all I could get, this works. Basically, when you want to start the program you run a script not the main file. This script flips in the libraries that make the the program work, and then flips them back out when it is done. It means you only get to run one program at a time but sometimes that is the best that can be done.

Many times even when the alleged source code for a program is published, you can't make it compile unless you have exactly the same system as the author.

Moose On The Loose; It`s almost as if trying to deal with and fix standard builds is sort of hopeless, it`s never really going to be right anyway.

amigo commented on the hassles of static builds, so I suggested making a set of tools to automate the whole process as much as possible.

Again... A few extra sets of SFS lib. add-ons would potentially make static builds smaller and all builds would have a better base.
Short of this, those libs. might be best built with Puppy in a variant. But making a Puppy variant for each special purpose is nuts.

Moose On The Loose; It`s almost as if trying to deal with and fix standard builds is sort of hopeless, it`s never really going to be right anyway.

Sometimes there just is no better way than to fiddle with libraries until the program works. It would be very nice if absolutely everything I will ever need was available but really that is too much to hope for. I can either reboot into a different Linux distro to get those program or fiddle.

Unfortunately, it isn't something that is really worthy of making into a *.pet. I've got the things I need to work so I'm using them as they are.

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