Puppy build system alternative?

[wiak]

Personally, and I only advocate my preferences as one member of this Murga forum community, if I were wanting to use/adopt repositories from any particular distribution I would prefer to also use/adopt the package manager used by that distribution since it is carefully tailor made and maintained. Repos databases are designed with a particular format which is carefully matched by the related package manager. Puppy used to use its own package repos and format for these and hence a specially created Puppy Package Manager was needed and created. The limitation to that was the difficulty maintaining these repos and one result of using them was not many packages available so bigger repos adopted (but without also changing to the appropriate related package manager... that's a pity I feel; dotpets could always have been easily converted whenever required).

Puppy users have long been able to replace Seamonkey with FIrefox, or Chrome, or whatever - nice if Pups could change flavour in similar way simply by pop-in official package manager of alternative upstream repos - so Core Pup + Alternative Package Manager/repo (e.g. Debian/Ubuntu, Slackware etc) would produce a different main Pup flavour rather than having to continually hack away at PPM to make it also work with alternative repos.

Not saying I'm planning to build any such 'Pup' but who knows.

wiak

[jamesbond]

@s243a: unfortunately "corepup" falls into the category of "instructions spread over 100s of pages" ... and it doesn't produce a distro. So no, that wouldn't fit here. May be I should make clarify that the given build system must have already an ISO or LiveUSB images that can be downloaded and used (doesn't matter if it's still buggy / alpha / etc, as long as it is available for download and testing and use).

@fredx181: thanks for the info!

@ally/@musher0: Thanks, I'm aware that nosystemdthanks is doing that, but I'm not sure of it readiness since he has not announced it himself yet (he has only announced the idea) - unless I miss that thread where he announced figos. So for now I'm going to keep it off the table, but I'm happy to be corrected.

@wiak: Although the instructions are certainly extensive and clear (thumbs up for that!), I will skip dCorepup because it does not produce a "distro" (LiveCD, or LiveUSB images) that can be distributed to others.

As for the PPM vs native package manager of parent distro - my preference leans towards native package manager too. But there are other aspects that is tied to a choice of package manager, too complex to be discussed here.

[wanderer]

hi jamesbond and everyone

here is my (unsolicited) opinion

2 problems have dogged this issue

1. people don't want to use github

2. this kind of project has never been identified as a puppy
and has no identified team behind it
so people just keep thinking its another distro
that was mistakenly placed on the puppy forum

getting around github is easy
just have a repository of components on the forum
and 2 scripts
1. a universal component builder script and
2. a distro assembler script that uses the repository

then a simple list of components can be made
this will define and save each distro
for reference and replication
and then the assembler reads the list and puts it together
if another component is wanted
the universal component builder script makes it
and puts it in the repository

we also need to start a puppy community project
and call it puppy (no matter what the base is)
to make sure it is seen as a "puppy" and not just a "pup"
and assemble a team of volunteers to work on it

i volunteer to join as a tester and general annoyance

i propose the name be
"the non official non woof-ce non github puppy community project"
or the "nonwngpcp" for short
just kidding we need to have a good name
any suggestions ?

i propose we use corepup/tinycore/dcore as the base
because it is already complete and is being actively developed
and cannot be beaten for size simplicity and flexibility
(the core is 6 megs beat that with a stripped down puppy other than pupngo)

it already has (almost) all the things needed
this will save us years of work
and get things going right away

the problem of sfs vs tcz is a non issue
since they are totally convertable

the only thing missing is a universal component builder
fredx portable firefox script is a great example
just a few lines long
and it downloads and builds a magnificent portable application

i can (and am doing it now)
write a 1 page set of instructions
on how to make a unique corepup distro
it only takes a few minutes
and anyone can do it (even me)

as i said corepup has everything we are talking about now
with the exception of a universal package maker
which i am working on now (or begging others to work on)

anyway and either way
i will continue to work on corepup
which as i mentioned
is already the system we are talking about

regards

wanderer

[jamesbond]

wanderer,

You have interesting points, but some of them are out of topic. I will respond to those that I consider relevant, but that doesn't mean the rest of them aren't useful, it's just that there is another place and time for those, just not here.

1. Github - I will skip the details, but I will only say this (to everyone who doesn't like github, not to you personally): if github is hindrance, then by all means, grab Woof-CE tarball, and host it yourself elsewhere. But just as the github proponents can't convince you to use github, don't expect them to use whatever workflow model that you propose.

2. your quote "we also need to start a puppy community project and call it puppy"

That would be ok as long as the stewards agree that the outcome of that project can be called a Puppy (or Puppy CE).

Why the need for such seemingly bureuacratic approval? The reason is simple. If anyone can call his or her project "Puppy Linux" as they like, then the word "Puppy Linux" will lose its meaning - one can literally take any distro, add a few dog wallpapers, and call it as "Puppy Linux". That is certainly not the future we're looking forward to.

In fact, as you remember, in the days of Barry, the community need to get Barry's approval too, to start start "Puppy CE" project.

Another illustration, which I said earlier elsewhere: you can't just start a community project to build a new web browser and simply call it "firefox", without any approval from Mozilla (which in this case are probably __NOT__ going to allow you to do that).

But I guess before you try to get the approval, it's better to rally support behind it. Perhaps you can start a poll or something ... and if you have enough numbers, I don't think the stewards would object. After all, Puppy world is a do-ocracy; if we have a ton of people standing behind an idea, it will happen no matter what the final name is.

3. your quote: "i can (and am doing it now)
write a 1 page set of instructions
on how to make a unique corepup distro "

I appreciate you doing that. But I just want to remind you that "distro" (=short for "distribution") is a tangible thing. The end product must be something that you can package into an LiveCD ISO, or LiveUSB image, that can be uploaded somewhere, and other people can download somewhere; in other words, something that can be "distributed".

If the instructions only explains on how to do certain stuff so that tcore/dcore behaves like a puppy, then by definition it is a "customisation instructions" and not "instructions to build a distro", so it won't be considered as a build system.

Of course it being considered as a build system or not probably doesn't matter to you.

However, I just want to say that not having an ISO probably counts as one of the reason why corepup isn't as popular as you expect. While there are people who are willing to follow your instructions, there are still many others who prefers to download something and have it installed without having to follow 50-odd steps to "make it work". I have seen many people peeked into corepup thread, and asked "where is the ISO" and the answer has always been "there is none, just get tcore ISO instead and follow the steps". That's probably OK for a personal distro on one machine, but if I have four PCs, I certainly don't want to repeat all those steps on each one of the PCs.

Good luck on your corepup effort.

[wanderer]

hi jamesbond

thanks for responding to my drivel

yeah i didnt think of a lot of what you bring up

im not concerned with the success of corepup
its just fun for me

but what in your opinion would constitute a build system
would it start with a single script
and where would it get its components
wouldnt the iso just be a product of the build system

i know im dense
but i am really interested in this
because i think it would help a lot of people
make things and feel more included

anyway just ignore this if it is off topic

no offense meant

wanderer

[Lobster]

Came across this on the wiki, might be relevant/updateable
http://wikka.puppylinux.com/remastering

[wiak]

@wiak: Although the instructions are certainly extensive and clear (thumbs up for that!), I will skip dCorepup because it does not produce a "distro" (LiveCD, or LiveUSB images) that can be distributed to others.

Yes, I described it in the form of a HowTo - the result indeed being customisation of what I declared remained pure dCore aside from the added customisations. But why would that be particularly different from the various DebianDogs?

dCoreDog uses official dCore distribution from tiny core including the necessary LIVE boot components in the form of its initramfs (initrd as they call it...): dcore-xenial.gz.

StretchDog, for example, uses official Debian build underneath (created by official Debian debootstrap script as it happens). Following a chroot into that, everything else is basically also 'customisation'.

The only "buiid" difference of dCoreDog compared to StretchDog (aside from relying on tinycore dcore as the 'base' system) is that I haven't scripted the HowTo, which is actually quite a trivial matter (also dCoreDog needs a lot of polishing to reach the maturity of StretchDog, but that is something that just needs more detail). The result would indeed be a customised version of official tinycore linux dcore-xenial iso. StretchDog is a customised version of pure Live Debian (certainly it can use a special Porteus boot initrd, but could instead use the official Debian live boot initrd's alternatively; indeed saintless preferred using official Debian live initrd in his original JWM-based DebianDogs).

Same could be said for corepup (if step by step instructions given and then scripted) so it does seem to me you really are 'moving the goal posts' to suit some build model you have in your own mind; but really you'd have to exclude StretchDog if you do not consider that dCoreDog does not fit in your first post description (same goes for corepup if step by step instructions were provided by wanderer it seems to me). Even without dCoreDog having a script, it still does, it seems to me, (almost) satisfy your (except needs extra steps to polish up to Puppy expected functionality):

Code: Select all

2. Step-by-step instructions, which can be followed by others, to produce a Puppy-like distro. ... Ideally, (1) and (2) should go together but I'm willing to accept (2) without (1) with the provision that it has enough detail so that a capable person would be able to automate it to produce (1).

If it is only about also making a unique initrd, then only Porteus boot mechanism of the DebianDogs does that in a sense, but as I say you don't need to use Porteus boot with the DebianDogs (tho I do). If you want a truly independent Puppy build then I suggest neither DebianDog type system nor dCoreDog etc satisfies that wish but then we are stuck again at square one saying only woof-CE currently satisfies the criteria of producing a unique Puppy distribution; unless you want FatDog to take over the mantle of the next Pup (since it also seems to be a truly independent system (but then so is Void Linux in terms of not being simply Slackware or Debian derived).

So I guess my question comes down to what defines an acceptable Puppy build system since I don't think your first post is proving clear about that.

Really you can't justify the DebianDogs being acceptable when dCoreDog, or corepup are considered somehow not. As for TazPup, well that's primarily a method of bootstrapping pure Slitaz via Puppy boot scripts (with benefit of some Puppy functionality in terms of save persistence and run-in-RAM capability occuring (but there are mechanisms in versions of Slitaz iso that can also provide similar functionality anyway - loRAM version of Slitaz, for example, comes with aufs kernel and save persistence via that).

I'd thus like your view of acceptable build systems clarified further.

EDIT: But I agree that dCoreDog shouldn't be included for the simple reason that it isn't complete enough (even if scripted as it is) and also because I'm not planning to work on that further so it will likely never become completed enough to be worth including.

wiak

[wiak]

I'm not, by the way, personally advocating dCore or tiny core more generally as my preferred approach to any new Puppy build. As far as I feel, these, like the original DebianDogs are not Puppy and are not trying to be Puppy - they are simply trying to include some expected functionality we have grown accustomed to in traditional Puppy Linux. Tiny Core is not Puppy; Debian Live is not Puppy; Slitaz is not Puppy; Void Linux is not Puppy.

However, a mongrel system, could be designed that isn't quite any of these either, and in that sense might be a possible future model for Puppy itself. Personally, I'm interested in Void Linux being molded such that it acts like a Pup - once again, a puppified distro - not that that term means much; there are many live distros nowadays (and wasn't Knoppix and DSL such anyway).

It boils down to: what do we want Puppy to be. If current woof-CE produced Pups is the end of the matter then so be it - but I have doubts about that build system as well as the end reliance on big distro repos (which seems contrary to what Puppy was originally about). Fact is, in practice, IMO, it becomes better/preferable to use a Debian Live system, or. alternatively, I find, Void Linux (though that needs worked on to produce Live version with persistence and so on - but that is not difficult to achieve). So, for me, a modified, customised, altered boot for Void Linux would produce a wonderful Pup; better, it seems to me, to depend on Void repos and the excellent Void package manager, than huge dependencies implicit in using Debian repos (etc) along with far-less-than-perfect PPM (despite the hacks to improve its Deb dependencies etc abilities). I certainly doubt a return to the 'old days' of a truly unique Puppy with its own repos and so on - the manpower/organisation for all of that is too great or such uniqueness would never have been abandoned in the first case. Mind you, Void seems to have managed (to create and maintain significantly sized repos of its own) - but then, why bother to totally reinvent the wheel (hence myself planning to use 'puppified' style of Void as a woof-CE Puppy alternative - but yes, FatDog could be a better Pup, IMO, than woof-CE produced pups, and nothing is more pup-looking from User Interface point of view than FatDog - but how big are the repos? and how do you maintain them??).

wiak

[wiak]

To cut my comment short, I should add that:

some would prefer unique Puppy (which no longer really exists)

some tinycore base (wanderer)

some Debian Live base

me: Void Linux base (EDIT: though I'm not really fixed on that - it's just a current interest that I see potential in)

etc etc etc

I feel that Puppy should be such a mongrel that it allows for any and all of these (and more) therefore. Hence what nosystemdthanks wrote about basing Puppy design on a specification (rather than absolute implementation details) is a good idea. Whether his fig system should be used is another matter (but maybe - it's the only such attempt I've heard of anyway) - but overall I think the implementation of the spec creator/parser should not be forced as fixed by the specification design either.

Implementation? First we need a definition of what Pup is or more, what Pup is to be. Any implementation that satisfies the definition should be acceptable.

EDIT: So more generally I actually like the idea of a very flexible approach that encourages experimentation and difference. Modular, pick and choose parts: not just browsers and windowing environments, but also repos/pkg manager combinations, and choice of basic system type such as single user/multi-user/containerised and so on - like a Lego set (a term I think wanderer used, which is another way of looking at it). Certainly implementation of some parts requires knowledge/technical-skills in these areas, but developing ourselves as developers is part of the reason Puppy has existed for so long already. But I suppose this is almost off-topic since there is no build system for any such distro as yet.

wiak

[wanderer]

hi all

just a question

wouldn't a universal package builder (not package manager) be a good place to start

then packages could be made from all the various systems
woof-ce puppy tinycore debian fatdog void etc

and then snapped in and out like leggos to a
(very small and simple) puppy-like core
like pupngo
with another simple script (the loader script)
using a simple list as a template

this might unify all of our efforts into an alternative
(simple fast unique) "real puppy" build system

it should not be that difficult (since its not a package manager)
the steps would be

1. obtain the application
2. unsquash with uextract into a folder
3. resolve the dependencies

leave as an unsquahed portable app
or make into an sfs or tcz

i am working on this for corepup
and i am actually confident
that even i will be able to do it
(eventually with a lot of help)

wanderer

[jamesbond]

Responding to wanderer:

but what in your opinion would constitute a build system
would it start with a single script

It could be a single script, multiple scripts, C programs, C++ programs, and any combinations thereof.

and where would it get its components

Anywhere. It could use existing ISO, or it could get binary packages, source packages etc. The script could demand that the needed files must already been available in a certain directory, or it could automatically fetch them from the internet, etc.

wouldnt the iso just be a product of the build system

Yes, the ISO is the primary product of a build system. If it cannot produce ISO (or LiveUSB image) then it is __not__ a build system.

PS: In this thread I'm specifically talking about "distro build system".

---

wouldn't a universal package builder (not package manager) be a good place to start

Not necessarily. My understanding of "package builder" is "a system that will build binary package from source code". "petbuild" is one of them, and there are many others. In this forum, "srcpkg" made by "amigo" used to be very well know for that purpose.

then packages could be made from all the various systems
woof-ce puppy tinycore debian fatdog void etc

Ah then what you have in mean is "package converter", that is, convert packages from whatever parent distro to a native package.

Before you can have this, you have to decide on what package format you want to use. You can use existing ones, or ceate your own.

For example, for PET package format, we already have something like that: txz2pet, deb2pet, etc (need to expand to support void package, etc). But I think I'm quite certain you aren't going with PET

and then snapped in and out like leggos to a
(very small and simple) puppy-like core
like pupngo
with another simple script (the loader script)
using a simple list as a template

You've got the correct idea. This is what a distro build system does.

it should not be that difficult (since its not a package manager)
the steps would be

1. obtain the application
2. unsquash with uextract into a folder
3. resolve the dependencies

leave as an unsquahed portable app
or make into an sfs or tcz

Ehhh, not that easy. Are you going to put all dependencies of one app into one tcz?
If yes: that means multiple copies of libs/dependencies on multiple tcz.
If no: that means you will need to create a special "libs-only tcz" that other tcz depends? How do you sort out the dependencies, will you offer automatic dependency resolution (between these tcz-s)
What if the a new tcz needs a library that isn't currently packaged elsewhere? Are you going to pack it to that tcz? What if later on, other packages depend on that library too?
How to handle tcz that requires conflicting library versions?

And that's just on top of my head. May be there is more.

Nevertheless, I like th enthusiasm and optimism. Don't let my comment above stop you. These are problems that can be addressed, one way or another. I'm just pointing it out so that you can look a little bit further.

Good luck with your new distro build system project

[jamesbond]

Responding to wiak:

I don't move the goal post. Let me try again: The main reason I don't include dCorepup documentation is this (bold for emphasis):

2. Step-by-step instructions, which can be followed by others, to produce a Puppy-like distro.

The instructions should end up producing a distro, that is, something that can be distributed (ISO, LiveUSB, etc). It is not enough to only customise a live running operating system on a user's computer, as that is not distributable.

DebianDog's build system can and will produce ISO, as proven by the availability of various versions of DebianDog ISOs for download from its website. StretchDog is actually available as an ISO that I can download.

The secondary reason is:

... Ideally, (1) and (2) should go together but I'm willing to accept (2) without (1) with the provision that it has enough detail so that a capable person would be able to automate it to produce (1).

The steps you gave has a difficult requirement to automate: it requires you to __boot__ into the dCore itself. While it is not impossible, it is relatively difficult to perform an automated build system that requires the builder to actually boot into the "source ISO", perform all the transforms, produce the ISO, and boots back to the builder's original OS.

If you want a truly independent Puppy build ...

I never say the word "independent" nor "unique" and I mean it. I have tried to be very clear: I accept all kind of scripts (or even instructions, if they can be scripted) that will produce a distro (that is, ISO/LiveUSB) that is Puppy-like. I accept tools that builds distro from existing ISOs, from loose binary packages, from sources, or any combination thereof. I think that is a wide-enough catch.

I hope that clarifies. If you still have doubts, please let me know what __you__ think is a distro build system, and perhaps we can clarify the misunderstanding.

As for TazPup, well that's primarily a method of bootstrapping pure Slitaz via Puppy boot scripts

It produces an ISO, so it is a build system. As I said, I'm looking for build system that builds "Puppy-like" distros, not only "purebreed Puppy", and tazpup is certainly "Puppy-like" enough. We can disagree on the level "Puppy-likeness" of tazpup, but that's a different matter entirely.

---

The rest of the comments are off-topic. But they're interesting enough, so I'll address some of them.

As far as I feel, these, like the original DebianDogs are not Puppy and are not trying to be Puppy - they are simply trying to include some expected functionality we have grown accustomed to in traditional Puppy Linux.

That, my friend, is one of the definitions of "Puppy-like".

It boils down to: what do we want Puppy to be.

And therein lies the problem. "What do we want Puppy to be" depends on the "we" that you ask. There are as many opinions as there are headcounts here, or maybe more. Some "wants" even conflicts with each other.

But this isn't new. How did this get resolved in the past? Do-ocracy. I'm not sure if you remember about Puppy Saluki (by that time, the "next gen" Puppy). There was a long thread about how it should be, about how it should look like, etc. But nothing happened. Jemimah came, build something according to her own vision, and she got the name Saluki attached to it. It wasn't exactly "official" Puppy (the "next gen" thing never happened, Barry continued to churn ouw new Puppies according to __his__ vision, not whatever was discussed in the Saluki thread).

Another story. Fatdog was started by one person, kirk. I liked it, used it, and was invited to join, which I agreed, because I shared his vision. There were only two of us for many years, and then we saw SFR contributed a lot, so we asked him to join. Same story with step. So there are four of us now. We didn't start by asking "how Fatdog should be". Kirk just created it. And I like his vision. So is SFR. So is step. That's how we ended up together.

So I guess there isn't much point on asking this question, not because the question itself is inherently useless, but because all your hear as an answer is chaos. You have seen Puppy CE being developed a couple of times. The most difficult part of it is to find a compromise so that a reasonable Puppy could be built, if at all.

If you have vision on what Puppy should be, just go and build it. Or perhaps, start a poll and try to rally some people to support your idea. But it would be much easier to get traction if you already have something to show for it.

Or, alternatively, perhaps it is easier to start from something that already exists (and then build upon that). This is what I'm doing - to find out what already exists.

why bother to totally reinvent the wheel

Control. Compiler bug? Patch the compiler and rebuild. Xorg bug? Patch Xorg and rebuild. Need to insert an add-on to Seamonkey as a default add on? Add the add-on to the recipe and rebuid seamonkey. Package sizes too big? Rebuild using various "size-minimisation" techniques (-Os, dropping seldom-used libraries, etc). You can't do that if you depend on someone else's repo. You can patch after the fact, the seamonkey part is probably easy, but how do you handle Xorg bug for example? The way that Woof-CE deals with this is that they create their own "build" of Xorg which is pinned and prevented from being updated from by the parent distro's version. I'm not sure how DebianDog does it now, but I remember discussing this with Tony and he commented that he used similar tricks.

but yes, FatDog could be a better Pup, IMO, than woof-CE produced pups, and nothing is more pup-looking from User Interface point of view than FatDog

Well, thank you for the compliment. But at this point I think Fatdog will stay as Fatdog. Is it inspired by Puppy? Yes. Is it "Puppy-like"? Yes. Is it going to be the next Puppy? I don't think so.

but how big are the repos? and how do you maintain them??.

About ~1900 packages on the last count, not counting contributed packages and SFS-es. How do we maintain them - we have a build system (not the "distro build system", but another one) that build packages from sources using "recipes". Parts of this distro maintenance system is released in Fatdog's devx (or also as individual package in the repo, called "fatdog-pkgbuild"). With this, we can rebuild everything from scratch (starting with an empty directory) and build everything from source, from the native gcc compiler, glibc, all the way up to palemoon and seamonkey. Then the "distro build system" will take over and take these binary packages to produce an ISO. When a new version of a software is released, we tweak its recipe, run ./all-rebuild.sh and a new binary package is produced. Then we upload it to the ibiblio's repo using rsync. Easy.

Of course I'm only telling you the rosy part of the story. If you want to read the full story read it here.

Hence what nosystemdthanks wrote about basing Puppy design on a specification (rather than absolute implementation details) is a good idea.

As noted above, the issue is "who gets to decide what gets into the specification" because obviously you can't have conflicting requirement goes into it.

Implementation? First we need a definition of what Pup is or more, what Pup is to be. Any implementation that satisfies the definition should be acceptable.

To a certain extent, yes. But to be effective, you need a "reference implementation", that would be the flag-bearer, the Puppy Linux official.

Because, spec or no spec, we all know every puppy dev will just build things that he/she wants to build.

---

In summary - in this thread I just want to know what are the realistic options available, which we can use to build something Puppy-like, today, other than Woof-CE.

I already learn something here: that DebianDog has a build system. You probably already know about it, but I didn't (I kept thinking that it was a manually remastered Debian Live). I'm sure I'm not the only one. So it's good to know what's on the table, here, today.

Ideas are good, and should continue to be encouraged, fostered, and explored. But like any ideas, they may not pan out. The devil is always in the details. At the same time we need options now. So while continuing to explore ideas, why not look at what is readily available today. We can learn from these too.

[musher0]

Hello all.

IMO, we need a build system that takes into account the quality of the
apps. But does such a build system exist?

E.g. gmeasures is not good for any user operating with an UTF-8 non-
English locale, where the decimal is announced by a comma ( and
not a period ).

Don570's PuppyUnits is much better suited to this global market age,
but no Puppy dev is replacing gmeasures with PuppyUnits. Why? Are
all Puppy devs sleeping at the wheel? Is it peer-pressure? Or what?

Or if the dev has the frustrating-to-the-user mentality: "it's an old app,
but it will do." E.g. urxvt 9.22 has been out for a couple years ( latest
v. as of this writing ). It includes all sorts of new, advanced, settings
that enable one to create what I call "quasi-GUIs". But Puppy devs still
include urxvt 9.05 from 2008.

Same with the latest Bash, and the squash tool-kit. Etc., etc., etc., etc.

After a while, you discover it is a pattern of behavior. You get the distinct
impression that Puppy devs are a bunch of uncaring lazy-bones who let
their users do the testing.

The reason: "Oh it was not in the Debian | Ubuntu | Slackware repo."
Yeah, sure. To me, it means that the dev does not have a demanding
enough mentality, to improve on what's handed down to him.

How silly and narrow-minded. How furious that makes me, too, when I
know that the malleable Puppy structure would lend itself so well to being
cutting-edge, and what is holding it back is human lack of ambition and
thoroughness, and not enough intellectual curiosity.

How misrepresenting -- in the absolute sense -- that is to the newbie,
of what a Linux system has to offer him / her. If Puppy XYZ is not
providing the latest good version of an app, can you imagine the
frustration of the user, his / her justifiable anger at us when (s)he finds
out? Not to mention the precious time this person may lose trying to
update the Puppy. So we have a responsibility here.

Not that all apps should be latest versions; one has to use good judgment.
But when the app comes from a known reputable source with good
internal quality assurance, one should not hesitate to override the build-
system and include the latest version.

In this pattern, I also notice a bias in favor of gtkdialog-, yad- and GUI-
based utilities: Puppy usually has the latest version of those, But not of
Bash, urxvt or generally the CLI-based utilities.

Puppy also has a fascination for anorexic. E.g., Busybox is useful to pass
the chroot border, but after that there is no reason to use a maimed
busybox applet over the real utility that has the complete functions or
settings.

The top "Useless & Comical" prizes have to go to this or that dev who
occasionally comes up with a script to restore a property removed by
the busybox team -- when the original utility already had it!!! The reason?
The person didn't research the Web well enough beforehand.

I mention busybox. In fairness, i must add that the speedy ash interpreter
can be found nowhere else. Also, it could be any cut-down app.

My fundamental idea here being: a Puppy dev should ask himself /
herself: am i reinventing the wheel with this project ?

All this to say that no build system will solve the above shortcomings.
Human qualities of ambition, alertness, thoroughness and good research
might, however.

BFN.

~~~~~~~~~~~~~
Disclaimer --
Please, no "personalities". If the hat fits, wear it, but the above is not
meant as an attack on any particular dev or Puppyist. I'm trying to speak
in general terms, my only goals being those of offering food for thought
and of improving the production of Puppies.

[dancytron]

Hello all.

IMO, we need a build system that takes into account the quality of the
apps. But does such a build system exist?
/snip lots of stuff
.

That not really what a build system (especially as James defines it) does. That's what the person using the build system does by choosing the inputs to the build system.

If you look at something like Debian, there are literally hundreds of people maintaining, evaluating, testing etc to try to only have "quality" apps in their repository that actually work and actually work together. There is no way to automate that process into a script.

[wiak]

If you have vision on what Puppy should be, just go and build it. Or perhaps, start a poll and try to rally some people to support your idea. But it would be much easier to get traction if you already have something to show for it.

Well, I am working on something, but I sometimes take a year or two before I actually get round to building something (if at all)!

Actually, I have never been interested in building a distro by myself and not really had much interest in contributing much to distro building. I simply used to like developing small utilities or other simple programs or experimenting with system level functions/utilities I would write in C. For these activities, I's simply use whatever already-created distro that I liked. HowTo's such as dCoreDog were as far as I'd go since really just documenting for myself what I did to install any particular distro, such as tinycore, which does tend to need built up like a lego set (i.e. backup documentation store).

More recently, I tried Void Linux (after reading positive reviews of it) but found it wasn't really set up to be used as a Live frugal install with persistence. And prior to that, for some reason I forget, I decided to create makepup to see if I could address the reason I couldn't be bothered using woof-CE to build Puppy. Certainly I had also been active on DebianDog related threads but that's because I took a liking to dpkg/apt (having only used debian once before in my life but with little interest in its package management details). Anyway, things have come together to create my interest though it is more a distraction for me than a dedication.

A couple of things I particularly don't like about woof-CE:

Though it uses shell scripts to produce a build, these are interactive scripts that require constant user input. I hate that (which is what motivated me to write the fudge called makepup). Debian, more wisely I feel, created debootstrap system, which allows user to build a base debian (or fuller debian) system via commandline arguments (and hence easily further scriptable as in StretchDog-live script). If only woof-CE were re-written to be properly commandline driven like debootstrap - then it becomes easy to add a GUI to that (using yad, gtkdialog, or whatever).

The second thing is that the woof-CE scripts don't separate Puppy into a basic build plus optional extended versions (as debootstrap does).

As for Woof-CE: Woof-CE has two components:
1) "Woof-CE the distro build system"
2) "Woof-CE the puppy essential scripts"

So my issue is that woof-CE is too monolithic, making it a nightmare of a hack to modify it. If it were rewritten to produce a core build of a basic Puppy build system and then an intermediate stage or stages to include choice of repo/with-hopefully-that_repo's_native-package-manager and then a final separate build a whole appropriate Puppy distro stage (X and selected windowing environment and apps etc), then I could like that new woof-CE (assuming able to be driven from commandline. The builder could then choose to simple use the first stage to get a core build (since all these stages independent) and then write their own scripts to produce whatever type/flavour of Pup they want. Or they could use stage 1 + stage 2 and script the last stage themself. Or they could use stage 1 + stage 2 + stage 3 (which would produce a particular Pup out of a particular recipe someone (such as Phil or peebee etc) has produced for use by stage 3.

Main thing is: a proper commandline driven version of woof-CE broken down into a more modular structure and not 'requiring' user interaction.

Then there would be plenty of opportunity for interested devs to build various very different Pups but not just puppy-lookalikes (which are really not pups at all).

So again, somewhat offtopic - except that I'm talking mainly about woof-CE, which is one of the existing build systems. I'm not saying woof-CE should be further hacked to try and make it like I describe. Rather, I'm talking about a new woof-CE build system, build almost from scratch, but using the core part of the Puppy boot system so the build will still be Puppy (though of course that core boot system needs to be a modular too since all things need development over time).

wiak

EDIT: I note wanderer (good on him) is furthering his own points by quicking making some new build system of his old as a demonstation of his core + extras ideas (using existing woof-CE distro component parts). We do however need something that will keep up with Linux/app developments so whatever does get produced has to be upgradable and not stuck with limitations of any old pup.

I certainly do think new build systems for Puppy or puppy-lookalikes will result from all the current interest in this (and from the more-than-I-alone dis-satisfaction in current woof-CE monolithic complexity).

[foxpup]

Main thing is: a proper commandline driven version of woof-CE broken down into a more modular structure and not 'requiring' user interaction.

This reminds me of what sc0ttman has done for a package manager, with pkg.
.

[jamesbond]

I try to take the focus from Woof-CE, since this is about "alternative to Woof-CE" thread, and since Woof-CE seems unredeemable (because those who want Woof-CE to change won't touch it, and those who work with Woof-CE won't change it), I thought there is no point discussing it ... but it seems that we always fall back to discussing Woof-CE. Oh well

Though it uses shell scripts to produce a build, these are interactive scripts that require constant user input. I hate that (which is what motivated me to write the fudge called makepup). Debian, more wisely I feel, created debootstrap system, which allows user to build a base debian (or fuller debian) system via commandline arguments (and hence easily further scriptable as in StretchDog-live script). If only woof-CE were re-written to be properly commandline driven like debootstrap - then it becomes easy to add a GUI to that (using yad, gtkdialog, or whatever).

This is a valid concern.

Rather, I'm talking about a new woof-CE build system, build almost from scratch, but using the core part of the Puppy boot system so the build will still be Puppy (though of course that core boot system needs to be a modular too since all things need development over time).

I did that, 5 years ago. It is the "woof-next" branch of Woof-CE. I took the puppy essential scripts, separate it from the build system, and then created a new build system.

"woof-next" did not build complete full-featured Puppy. I put only enough packages to get it to boot to desktop. No abiword, no gnumeric, no nothing - just minimal CLI tools and minimal Xorg + jwm + gtkdialog + xdialog. I think that's "barebone" enough, although you certainly easily drop the Xorg component altogether and create a fully CLI-system only if you want (in fact, that was how I started it).

It was command-line driven; all controlled by config file + package-list file. There was a clear separation between "puppy essence scripts" and "build scripts". It supported debian/ubuntu/slackware, 32-bit and 64-bit (arm was planned but was never materialised). Separate builder script for different parent distro. It builds everything up to an ISO, and it even has qemu script to boot and test that ISO. What else could you ask for

It did not use PPM. It used the parent distro's native package manager (apt-get/dpkg for debian/ubuntu, and pkgtools for slackware).

It sounds like it ticked everything in your box. I promoted it for about a year, few people tried it, some said they like it (=fast, etc), but that's it. No further traction. After a year and no traction, I decided to retire it 4 years ago.

Where were you guys who always say that you want to build a barebone puppy, or build "custom puppy" from barebones? This is as barebone as you can get - it builds from nothing; you've got to choose exactly what packages you want, down to glibc. This was your perfect chance, build a barebone puppy from scratch, customise __everything__ that gets included. But there was no takers other than some occasional testers ...

I purposely don't include it in the list because:
1. I don't do self-promotion,
2. It's dead, Jim! and
3. It officially is part of Woof-CE even though it is in reality a totally separate build system (which is why it was merged as a separate branch of Woof-CE, not the main branch).

In case anyone is still interested: it is located here: https://github.com/puppylinux-woof-CE/w ... /woof-next. The code still works, I just did a test build for Slackware. For debian sid, they have moved on too much, we need a new package list and more patching. For ubuntu, they have removed utopic and trusty repos, so can't build anymore. We need updated package list and patching for newer ubuntus.

This was the my original post about it: http://murga-linux.com/puppy/viewtopic. ... 4&start=15 (it is now a bit more than 300 lines; it is around 600 lines now). Original package list http://murga-linux.com/puppy/viewtopic. ... 843#780843 (it has grown abit more, I added gtkdialog, xdialog ...). Original thread about it: http://murga-linux.com/puppy/viewtopic.php?t=94101.

Quick note: I'm not about to re-open the project. For me the project is over. woof-next is there for everyone to see, learn, and use as they see fit. Fork it and make it better if you will. I can answer questions but please don't expect me to make code change or anything.

[wanderer]

hi jamesbond

i would like to try your system

i dont want to clog this thread with questions about it

since it is off topic

is it possible that you could check

the alternative puppy build system thread occasionally

and answer a few questions

thank you very much for doing this

it seems to be a major part of what im looking for

also please accept my apology for constantly whining about woof-ce


regards

wanderer

[foxpup]

Where were you guys who always say that you want to build a barebone puppy, or build "custom puppy" from barebones?

2014, I was not yet Puppy, my excuse But I do remember something, vaguely.
Maybe just not enough 'guys'. There are still only a few who want to build from barebones. Most of us do the other way around: trim a successful/working build.
Maybe you were ahead of your time?
Maybe, it got 'snowed under' at woof CE which is not considered to be 'for everyone'.

Anyway, it looks like a valuable contribution to this thread.

[wanderer]

i am trying to run it now

if i can get it to work

it will be the base of the alternative puppy build system project


wanderer