Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 25 Aug 2019, 07:30
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Misc
Puppy build system alternative?
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 4 [60 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
jamesbond

Joined: 26 Feb 2007
Posts: 3357
Location: The Blue Marble

PostPosted: Thu 02 May 2019, 11:20    Post subject:  

Responding to wanderer:

Quote:
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.

Quote:
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.

Quote:
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".

---

Quote:
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.

Quote:
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 Smile

Quote:
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.

Quote:
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 Very Happy

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Last edited by jamesbond on Thu 02 May 2019, 11:43; edited 1 time in total
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3357
Location: The Blue Marble

PostPosted: Thu 02 May 2019, 11:21    Post subject:  

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):

Quote:
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:
Quote:
... 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.

Quote:
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.

Quote:
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.

Quote:
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".

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
musher0

Joined: 04 Jan 2009
Posts: 14283
Location: Gatineau (Qc), Canada

PostPosted: Thu 02 May 2019, 14:49    Post subject:  

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.

_________________
musher0
~~~~~~~~~~
Je suis né pour aimer et non pas pour haïr. (Sophocle) /
I was born to love and not to hate. (Sophocles)
Back to top
View user's profile Send private message 
dancytron

Joined: 18 Jul 2012
Posts: 1327

PostPosted: Thu 02 May 2019, 16:40    Post subject:  

musher0 wrote:
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.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1615
Location: not Bulgaria

PostPosted: Thu 02 May 2019, 18:18    Post subject:  

jamesbond wrote:
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).

jamesbond wrote:
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).

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
foxpup


Joined: 29 Jul 2016
Posts: 924
Location: europa near northsea

PostPosted: Fri 03 May 2019, 09:56    Post subject:  

wiak wrote:
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.
.
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3357
Location: The Blue Marble

PostPosted: Sat 04 May 2019, 11:39    Post subject:  

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 Smile

Quote:
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.

Quote:
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 Smile

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/woof-CE/tree/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.php?t=93904&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.php?p=780843#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.

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.
Back to top
View user's profile Send private message 
wanderer

Joined: 20 Oct 2007
Posts: 1111

PostPosted: Sat 04 May 2019, 14:21    Post subject:  

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
Back to top
View user's profile Send private message 
foxpup


Joined: 29 Jul 2016
Posts: 924
Location: europa near northsea

PostPosted: Sat 04 May 2019, 15:10    Post subject: woof-nest  

jamesbond wrote:
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 Wink 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.
Back to top
View user's profile Send private message 
wanderer

Joined: 20 Oct 2007
Posts: 1111

PostPosted: Sat 04 May 2019, 15:46    Post subject:  

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
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 2051

PostPosted: Sat 04 May 2019, 15:49    Post subject:  

wanderer wrote:
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


I suppose it depends on what you want but it might be easier to start with something that is already built like jamesbond's system.
Back to top
View user's profile Send private message Visit poster's website 
wanderer

Joined: 20 Oct 2007
Posts: 1111

PostPosted: Sat 04 May 2019, 16:24    Post subject:  

hi jamesbond and everyone

i have successfully built jamesbonds puppy

it has some tweaks to do

but works

it is now the official base of the alternative puppy build system

thank you very much jamesbond

please consider checking

the alternative puppy build system thread occasionally

as i will have questions


once again

thank you thank you thank you

wanderer
Back to top
View user's profile Send private message 
tallboy


Joined: 21 Sep 2010
Posts: 1420
Location: Drøbak, Norway

PostPosted: Sat 04 May 2019, 19:30    Post subject:  

jamesbond, it is good that you revoke the search for an alternative build system. You say you abandoned your project only a few years ago, but I think you have had build-systems on your mind for a long time. I think you touched the subject about 10-12 years ago too, but that was probably before woof. Very Happy
_________________
True freedom is a live Puppy on a multisession CD/DVD.
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1615
Location: not Bulgaria

PostPosted: Sun 05 May 2019, 03:25    Post subject:  

jamesbond wrote:

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 Smile

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.


In Dec 2013, I took an interest in saintless's "Light-Debian-Core-Live-CD-Wheezy", which progressed into the early DebianDogs. I continued to develop small app/utilities and made versions available for both these Dogs and also Puppies but otherwise wasn't following Puppy development itself for several years. For some reason, I utterly cannot remember, though following the ages I took to write wex, I took a look at woof-CE for the first time (perhaps I was comparing it to Debian debootstrap). However, I felt frustrated by its interactive design (constant user-input required), so wrote a simple frontend to answer all the questions automatically for me - that became makepup, but I never thought of makepup as anything but a fudge/workaround for something that annoyed me; as far as I was concerned woof-CE needed redesigned and re-written.

I did at that time then notice woof-next but no-one on the forum was talking about it by that time and I had no time myself to check what it's differences to standard woof-CE might be. It certainly sounds interesting though (indeed it sounds from your description to match almost exactly the features I feel would be good but which lack in woof-CE proper). However, like I've said recently and earlier, I've never personally been very interested in producing my own distro design so even playing with woof-CE for a while was not the sort of thing I'd usually bother doing.

As for now, aside from my frustrations with woof-CE itself, my real motivation simply comes from the fact that I decided to look into overlayfs operation for myself since I recognised I could use that to alter the operation of a running void linux, which was a distro I had become interested in because of its package manager xbps (which I noted had a commandline interface reminiscent of apt, at least from user's point of view) and independently-crafted repo; also, runit looked useful. Since I like learning by doing from first principles, I'm not myself interested in developing someone else's code (which is also another reason why I never involved myself directly with woof-CE). Indeed, everything I've ever developed was created simply because I wanted to practice with some new coding ideas or because I had a personal need for a particular kind of app/utility and liked writing my own.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wanderer

Joined: 20 Oct 2007
Posts: 1111

PostPosted: Sun 05 May 2019, 10:38    Post subject:  

hi jamesbond and wiak

i just made a distro with woof-ce next

it is a great system

just what we were always asking for all these years

very fast
easy to use
easy to download the blob
and easy to follow instructions

it needs to be developed

i am going to keep promoting it since it is too good to be neglected

but i cannot code so someone else will have to help me develop it

it makes a standard puppy

unfortunately for my project
like all woof-ce clones it weaves everything together
which is incompatible with a modular system

i will use my modular approach with my system
but will keep it as part of the alternative project

thanks again jamesbond for making it
and telling us about it
i had completely missed it when you made it originally


wanderer
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 4 [60 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Misc
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1407s ][ Queries: 11 (0.0032s) ][ GZIP on ]