I posted this elsewhere, but I think it is worth repeating my comment about woof-next here:
(this was a response to wanderer).
Be my guest. As I said, look at it, test it, learn from it, take it to pieces and use anything useful from it, fork it, improve it ... do anything you want to do with it.
My original intention when I wrote the post about woof-next is because you said "you wish there is a smallish woof-ce build system" so I want to say "well here we are, a 600-lines build system" which should be easy to learn (and perhaps adapt).
You __do not__ have to use it for anything if you don't like it; if you can learn from it to improve your own stuff that it has achieved its objective. But if you do want to improve it and use it as a base, of couse that's welcome too.
and also
(response to s243a)
But remember: the value of woof-next is its build system. Its "puppy essence scripts" which I extracted from Woof-CE is now very dated; and it does not include the new stuff; because I did not spend the effort to sync it from Woof-CE anymore.
Also, even back in 2014/2015 when it was still alive, woof-next did not build a __finished__ system. Look at my original posts; I offered woof-next for puppy developers who were interested in alternative build system, alternative package management (using parent distro's package manager instead of PPM), and interested in building barebones system. I was offering a __build system__ that can easily be customised; I was no offering a __alternative finished puppy__. Now "barebones" means minimal amount of packages; and this means some puppy scripts will not work because the dependencies were not included. These was meant to be fixed by the puppy devs: either by fixing the puppy scripts; or installing more dependencies that is needed to make it run.
@foxpup: What I want to find out is what is really core puppy.
That is a philosophical question. I know you have tried Fatdog, do you consider Fatdog as "Puppy"? Why or why not? How about DebianDog? How about Lxpup?
@foxpup: I do not want that core to be debian or slackware or ubuntu or bsd, but Puppy.
The last Puppy that wasn't based on others is Puppy Racy (and Puppy Wary for older machine). These were puppies where the package was compiled from source by Barry himself, using T2-SDE. There is no other Puppies like that ever since. The closest one you have is Fatdog; we compiled our own packages from source too; not even using T2-SDE but we use our own system (fatdog-pkgbuild).
@foxpup: It should not be minimal, but it should not have apps.
This is difficult question. Is "bash" an app or not? For someone who uses "busybox ash" as a shell, he/she will consider "bash" as superflous and therefore is an "app" and should not be in the core. But others (like musher0) will say that busybox is an abomination, we need "the real deal" like "bash" and therefore it is __core__.
I'm exxegerating but I hope you see my point - what is considered as "apps" by one, may be considered as "core" by others ...
@foxpup: It should boot to X and it should have the Puppy wm (jwm+rox)
wanderer will say that X is not core and should be in a separate SFS ...
----------
Anyway the point of a having a build system, is so that __you__ can easily specify exactly what goes into the system.
----------
@foxpup: The PM should be versatile enough to install packages from a lot of different repositories on the Puppy core.
This has been said too many times. I did not comment on that previously, but I'd say what I think; and this comment is not specifically addressed at you foxpup, but to everyone who thinks that "oh this is such a great idea!".
A counter example: Lets run Ubuntu Bionic (the real stuff, not BionicDog or Bionicpup, but the real deal). Then try to install a package from Ubuntu Xenial (for example, you can take any other versions other than Bionic). See if you can get it to run.
Case in fact: a change in openssl alone will make a lot of Fatdog 721 packages (that uses openssl) to fail to run on Fatdog 800. Even though all of these packages are compiled by ourselves!
Now you want to pick and choose packages from slackware, ubuntu, debian, devuan, tcore, redhat, opensuse ...
Don't get distracted by packages like "firefox" or VirtualBox that can be downloaded and run on many different distros. These packages are built in a special way, with special tricks, that most distro packages aren't.
Can an Ubuntu package runs on Slackware-based pup (or vice versa)? Of course. Under certain conditions. But if you expect that you can mix and matches packages freely from different distros will cause you a lot of grief.
"Pkg" helps you to install packages from different distro; and it does it well. But it doesn't guarantee that the installed package will run.