big_bass ,Amigo, ttuuxxx chit-chat zone?

[ttuuxxx]

Sorry to hijack your little triangle....

Jeff, Puppy does need better burning, sometimes bloat can be misleading.

HI-Jack anytime you want to Mick no problem
Yes I agree we need more Burning applications, I compiled the latest tkburn for series 4.2 since it has tcl/tk once again. Thats really small but it uses the older burning libs, not libburn. I really don't think that things like a 30MB K3B are really needed, its just way too much bloat for what it does. I'll try to take this burning thing further I have a little idea, I'm going to try, and see where that goes, if it works I'll release it on here and maybe we can work on it. I'm not the best at code but I'm learning, slowly but surely.
ttuuxxx

[amigo]

Having less software installed will not really make your system run any faster. To optimize a system for a low-end machine you need to use programs and libraries which use less RAM. Sometimes a larger program will use less RAM than a smaller one, but usually a small program means less RAM usage. The other critical thing to do is to not have unneeded daemons(services running). For Puppy, the size of programs installed becomes significant (vis-a-vis speed) because some or all of them are loaded into RAM even when not running -which leaves less RAM for running them.
On low-end hardware it is best to use a kernel which is fully optimized for the exact architecture.
For a i486 machine, you would really do well to use a system based on uCLibc(like deli linux) or the old libc5 (glibc-2.2 or earlier like slackware-8.1). These smaller libraries(libc is the main one mind you) occupy less RAM for any program which runs so you save RAM for any and all programs.

So Jeff, have you tried the build I suggested above using src2pkg?

[big_bass]

Gilbert


Wow!!!

thats nice........ I ran the demos and built the packages correctly
I still need to try this on puppy I tested on my slack box
I will have more time tonight when I am free looking forward to it

but so far looks great

a quick question I already have src2pkg set up
and updated to your dev version
the /etc/src2pkg.config.new

is the one I edited the lines you recommended in your email

which file is used as default ? .config or .config.new ?

A big Thanks I can't wait to try a few things tonight
I can foresee something adventurous coming soon

Joe

[amigo]

The /etc/src2pkg/src2pkg.conf file is the 'real' file. Slackware-type doinst.sh scripts (for packages that install conf files) use a special routine which rotates new conf files in, but only if the old ones were not changed. Study the doinst.sh for src2pkg itself to see how they work. The conf file is conatined in the package with the '.new' suffix. If you have never installed src2pkg, the file gets renamed by the doinst.sh to remove the '.new' suffix. But, when you later upgrade, the doinst.sh checks the existing src2pkg.conf against the src2pkg.conf.new file. If they are the same then the new one is discarded. In practice, this means that if the new conf file is different from the original, the '.new' one gets preserved and you have to merge the new changes yourself or ignore them. You'll see the '.new' files if you have edited the original file, or if the new version of the program has changes since the last release.

I'm not sure which was you last version, so it may be best to rename your src2pkg.conf to src2pkg.conf.old and then change the src2pkg.conf.new to src2pkg.conf and re-do any changes you made to the old file. Probably there are just some new options near the end of the file. But, if you were running 1.9.6 or an early pre-release of 1.9.7, then there was a major change in the syntax and the old file will not work anymore.

The interesting code which creates a pet instead of a tgz is located in /usr/libexec/src2pkg/15-make_package lines 14-57. I think you may be able to read the code there. For the moment, up to that point a ackage is treated exactly as for a slackware package, but then, just before compressing the package we do a couple of conversions. For now, if the package contains a doinst.sh it is simply moved and renamed to pinstall.sh -but this may not be the best thing to do. One could execute the script inside the package tree, but that won't always do what you want either. The routine should really check the current working directory and if it finds a pinstall.sh there, use that instead of the doinst.sh. The 'install' directory gets discarded -though the package description could be worked into Puppy somewhere -src2pkg already has a routine which will generate a package listing the same as what installpkg does when you install a package(the files get created in /var/log/packages). There is also a small routine there which tries to create a $NAME.pet.specs file for you -or if there is one in the CWD then it gets used. I'm unsure what the 'sanest' defaults are to use in *.pet.specs which are generated -it might be best to not do it all. Your comments on these subjects will help me decide and go forward

[big_bass]

Gilbert

thanks for clearing up the config .new question
I just renamed the other one .old
then changed the name to just .config


I sent you a customized slackware version of a puppy package maker
that builds puppy package on slackware (out side the puppy OS )

so you could have some scripts to see how it is done on an official package

check your mail


rats... I need to check the lines you edited for the pet package maker on src2pkg
I want to see how you went about it

will report back



Joe

[big_bass]

Gilbert


I patched and tested the dev src2pkg for version 4.12 puppy linux
check your mail if your are happy with it send ttuuxxx a copy
so he can start testing


Joe