Quoting Iguleder, from http://www.murga-linux.com/puppy/viewtopic.php?t=70758:
Puppy gained big amounts of fat during the transition from the 4.x series to the more automated 5.x series, which is built using Woof. Many packages that were included in the early Puppy 4.x series made their way into recent Puppy versions, although they were totally unneeded.
Additionally, although the high degree of automation gave Puppy developers more control over the choice of packages shipped with each release, it also pulled in lots of unneeded files and packages from other distributions, such as distribution-specific documentation. The intimate knowledge of each and every package included in the release was gone.
These statements are very misleading. There is no difference between how Woof builds a Puppy live-CD and how Unleashed (the pre-Woof build system) does it.
Puppy 4.3.1 was built with Woof. How? No difference from earlier 4.x puppies.
There are just a collection of PET packages. The build script, either in Woof or Unleashed, puts them together, and voila a live-CD. No difference.
The difference is in the extra functionality of Woof. Whereas Unleashed had minimal mechanisms for creating the PET packages, Woof adds extra automation. In Unleashed, I did have some automatic tools for converting binary packages compiled in T2, to PET packages. Woof inherited those same mechanisms, just extended it to handle binary packages from other distros.
Spelling this out again:
The Puppy 4.x series is built from base packages originally compiled in T2. In Unleashed, I used scripts to convert them to PETs, exactly as is done in Woof. The PETs can then be hand-crafted for smaller size -- regardless whether you are using Unleashed or Woof.
Now, for a difference with Woof. Importing binary packages from another distro such as Debian, Woof does not convert them to PETs, just applies automated conversion. So, without any hand-crafting, the packages may be bigger. However, they can still be hand-crafted by means of the template directories -- that is the new way of doing it.
Wary Puppy is an interesting case study. I compiled the sources in T2. I used scripts in Woof to convert the T2 binary packages to PETs. I did some hand-crafting of the PETs. I built Wary (and Racy) from those PETs. In other words, a process exactly like Unleashed, resulting in the same small size.
And indeed, Wary and Racy are very small.
So, Woof has extended the functionality of Unleashed, and in no way taken away from it.
Now, if someone building say, a Dpup, wants to make it smaller, they have various choices.
1. Tweak the templates is the recommended way, as that sets in place something that others can use.
2. Compile some PETs, hand-craft them. Which is what we already do. In fact, the Dpup that I created was built with some of my own PETs instead of the Debian packages, as mine had less dependencies and were much smaller.
3. Convert the Debian binary packages into PETs, then hand-craft them. This is what I did for Wary (from T2, not Debian). Woof has scripts in the 'support' folder to do this -- 2compat2pets, 3compat2pets -- they so far have only been used on T2 pkgs, might need some mods for Debian. Or, you can convert individual Debian packages to PETs then hand-craft them -- which is very easy, as the package is to be found in folder packages-dpup (or whatever name is assigned to the folder that holds the packages after they have been converted from the original .deb packages) -- just grab the package, hand-craft it, make it into a PET (dir2pet).
Comments:Posted on 32 Oct 2011, 8:17 by technosaurus
There were quite a few legacy scripts in woof the last time I checked, but that was quite awhile ago. Perhaps more importantly are the legacy bits and bashisms within the still-useful scripts. When I started working on bashbox about a year ago, I removed most of the legacy stuff and removed as many bashisms as possible, but I almost always end up rewriting them from scratch b/c the code was inconsistent (lots of patches from different coders and I am a bit ocd)
The current state has much more code reuse and should be portable even to nommu machines
The latest project will provide a single static uclibc multicall binary that act as the base X apps, from which any distro's packages can be pulled using their shared libs. Kdrive+xinit+jwm+rxvt...
Posted on 32 Oct 2011, 8:49 by Raffy
The 32-day-of-month bug is here again.
Posted on 2 Nov 2011, 3:52 by GCMartin
The Puppy Genereation system
I appreciate you sharing this. It allows readers to put in perspective what these 2 approaches mean.
You probably don't need to defend what WOOF does. It is a seasoned, mature, and provides about 10 years of system generation understanding that every distro owner needs to have in mind as they set to build a stable distro for consumption.
Further from a support standpoint, you being its maintainer, has been ever-present is yuor addressing the needs of the community of system generators.
Posted on 2 Nov 2011, 9:14 by GCMartin
The Puppy Generation system
I just read my prior Title where I "created" <ha-ha> a new word...albeit accidental.
Just wanted to mention that in my reading over past weeks, there is topics being raised in the area of functionality and size.
The size issues, I an asking for everyone's clarity on it >>> HERE
Please share anything you feel helpful
Posted on 3 Nov 2011, 17:25 by Iguleder1
Barry - I'm truly sorry if you feel offended; you got me a 'lil bit wrong.
Puppy 4.3.x is pretty much same as 4.2.x in terms of its structure and features; something identical could be built with Unleashed, with only Woof's features missing.
However, this changed with 5.x - take a look at the number of unneeded packages. Just compare the number of DEB packages used in your Squeezed Puppy with the one I used in Guy Dog - about half of the libraries could be removed.
If you combine that with the fact many package's aren't trimmed, you get the magnificient size of 120-130 MB.
Not to mention the huge dependencies of Debian packages - the gphoto2 package depends on huge libraries itself and weighs 1 MB, while I was able to build a 32 KB package without any extra dependencies.
Posted on 3 Nov 2011, 20:11 by BarryK
Re small size
But you are blaming Woof for that big size. It is not Woof's fault. That is the point I made. Anyone of us can compile a smaller gphoto2 PET and use it in Woof.
Some DEBs that could be trimmed more, can be done so by modifying the template. Or, they could be converted to PETs and manually-trimmed. Those points I also made.
In fact, there is nothing to prevent a Woof-build to be as small as Guy Dog. There is nothing intrinsically superior to your alternative build scripts.
Eliminate unused libraries, yes. That is an extra optimisation that could be added to Woof. For now, 3builddistro does have such a feature, that discovers unused libraries and leaves it up to the developer whether to remove them.
Posted on 4 Nov 2011, 24:41 by Iguleder1
The other way
We just have different points of view.
You prefer to go for the easy way (for a good reason - no need to build and maintain packages) - taking binary packages and trimming them.
However, I prefer the cleaner and more "done right" way of achieving the same (or better, in many cases) result - building them inside Puppy and doing the trimming (plus the trimming) automatically, using some build bot.
Sometimes it's impossible to reduce the dependencies of a package (e.g it's an executable linked against an unneeded library) just by removing files - that's why the Woof templates method isn't perfect. Building our own package is harder, but the result is much better.
Posted on 5 Nov 2011, 8:42 by BarryK
Re the other way
Ok, as you have implemented an automatic compile and optimise system, with minimum dependencies, within a Dpup environment, that is very good. As long as most of the libraries are native-Debian, so as to maximise compatibility with existing Debian .deb apps.
So really, you are doing automatically what we would previously have done manually, compile our own apps within a Dpup.
Then yes, within that context you are adding excellent functionality to the existing build systems.