minimal modular puppy (from fossapup64)

[wanderer]

hi taersh

i am now trying to get woof-ce to build the 2 base isos for the minimal modular system
this will be a long process since i have to figure out what woof-ce requires for it to make a bootable system

how do you test your initrd
do you simply replace the initrd in an iso of fosspup64

william

[taersh]

Yes, I'm using the .iso from FossaPup64 9.5 to test/develop the initrd.gz.
Though, most of the programs/tools have been created/developed under Tahr32 6.0.2 and Bionic64 8.0.

I got two PMs so far.
Am planning to upload either to my Google drive account or to my account at archive.org. Doing some final testings today/tonight.
I'm not sure yet, what to use, but as soon as I finished testings and decided Google/Archive, I'm uploading and sending the link to those two members who sent PM to me.

Looks good so far!

[wanderer]

hi taersh

great

i will follow along
and test when i see how you guys are using it

william

[wiak]

it would be nice to have a script that made pets into sfs files
so they can be used as modules
but that can come later

william

There's PaDS.
PaDS is already included into the initrd.gz I created - which is at 2311Kb yet.

Again, I'm asking for people to PM me to get a download link for testing the initrd.gz.

Is there some problem with simply posting the link on the forum. That way anyone so inclined might be tempted to try it and a few of these might decide they'd like to contribute ideas further. I'm already concerned that this forum doesn't seem to have so many active members/users as in previous years, but I may be wrong about that, but any obstacle (such as no public link) to people trying something new immediately limits the number who would bother.

As I've indicated previously, though I am interested to read about whatever Puppy developments occur, I am too busy with my own project distro(s) to be directly involved in testing or development in practice here (though I can sometimes, possibly, provide optional addons). I really think you should put your initrd 'out there' to encourage others to try it.

[taersh]

I don't see any need yet, to post the link officially on the forum, since nothing yet is developed. It's even not a certain fact that anything from within that initrd.gz will make its way into the Community Puppy. Perhaps getting 10 or even more people to test it by having the link public. This could also return 10 or even more people getting involved by posting on the forum, making suggestions or reporting issues and bugs. This could eat most of my amount of free time for developments.

So, at current state of development of Community Puppy I think two or three people doing testings and reporting issues and bugs to me by PM would be enough and surely can be handled by myself - of course. There will be a time I think, when the link is going to be posted for the public and/or all forum members.

[wanderer]

hi all

first let me apologize for wasting everyone's time
with my incessant and annoying posts

but
its all coming back to me
as i play with woof-ce and puppy internals again

for some strange reason i keep forgetting
what i have learned again and again

i love puppy
the finished product polished by gurus
the great people of the community
the genius code and innovation

but the design and build system of puppy i dont love

keep it simple

just symlink the extensions to an initrd

have a repository
a conversion script to make modules from outside sources
a build script to make the iso
and templates for each build

no layered file system
no copying files from the initrd to another file during boot
no saving the initrd on a branch
no big unstructured file that lists everything in a blob
etc

alas

trying to make puppy minimal and modular is a waste of time
because of its design and build system
(at least for me)

i have no reason to waste my time (again)

i now return to playing with tinycore/dcore
which i feel are designed more logically

no offense meant
im just signing off on my part of this project

i continue to use upupbb32 as my main distro (thank you peebee)
and the idea of a community puppy is cool
as are all the other projects on the forum

will follow along

see you soon

william

[taersh]

[wanderer]

hi taersh

bit off more than i want to chew

keep up the good work
looking forward to your initrd

fossapup64 is very modular already
so no real change in the community puppy

your initrd should solve the multiple sfs issue

william

[s243a]

hi taersh

bit off more than i want to chew

keep up the good work
looking forward to your initrd

fossapup64 is very modular already
so no real change in the community puppy

your initrd should solve the multiple sfs issue

william

Hello @wanderer

I have a pretty good script to delete buitin packages from an extracted sfs. It shouldn't be hard to adapt it to move the files into a new folder instead of delete them. If you take the base sfs of fossapup and move the core/cli components into a new base modual I bet that what what you'd be left with would be half the size or smaller (less than 50MB). It might resembels @wiak 's work except withoit apt/dpkg., which could be added via wiaks add-on if someone wanted it.

Anyway, such an approcah might get you closer to what you want.

[wanderer]

hi s243a

thanks for your help and compassion

my problems are that

1. i dont understand woof-ce well enough to know how it builds its iso

2. i dont know the minimal packages in distro specs that are needed for a base

both of these things would be known by a woof-ce guru
but im not a woof-ce guru

so i will simply be guessing
that would of course take a very long time
but even if i succeeded i would not know what i had done

for example i changed all the yes to no in distro specs
but instead of building an empty iso
it didnt even build an iso

i assume that removing things from distro specs is the key

and the idea of 2 minimal modular iso templates
1. initrd-shell and 2. main.sfs-base x
that can be added to by mounting additional sfs files
is a simple and i think very useful idea

but it is beyond my ability at this time to implement
so i will have to leave this to people above my pay grade

william

[s243a]

hi s243a

thanks for your help and compassion

my problems are that

1. i dont understand woof-ce well enough to know how it builds its iso

We can work on that part later. You don't need an iso to do the testing.

2. i dont know the minimal packages in distro specs that are needed for a base

I moved the following packages from the basesfs to a separate folder:

Code: Select all

acl
attr
audit
bdb
bzip2
ca-certificates
coreutils
cpio
curl
dbus
debianutils
devmapper
dhcpcd
dialog
diffutils
e2fsprogs
expat
file
findutils
fuse
gawk
gcc_lib
gettext
glib
glibc
gmp
grep
gzip
iptables
keyutils
kmod
libcap
libcap-ng
libcapnp
libgpg-error
liblz4
libmnl
libnl3
libselinux
libsepol
libsigsegv
libstdc++9
libsystemd
libunistring
libusb
lzo2
ncurses
ntfs-3g
openssl
pam
parted
pcre
perl-digest-sha1
perl-html-parser
procps
readline
sed
sqlite
squashfs-tools4
tar
util-linux
wget
wireless-tools
wpa_supplicant
xz
zlib

After converting the folder to an sfs file the resulting size is 33MB. This might be a good list for core cli components. I'm missing some stuff though from puppies rootfs but this stuff would be included if it was built from woof-CE. That said, I'll identify the missing components so that building via woof-CE would not be required. I moved the files with the following script:

This is the command that I used to run the script:

Code: Select all

bash -x ./move_builtin.sh --pkg-list mv_basesfs_cli 2>&1 | tee move_builtin.log

where "mv_basesfs_cli " contained a bunch of builtin-in packages that I wanted to move (if they were contained in the base sfs). The list of packages to move could be like above. However, what I used was a longer list that contained comments about the related items from DISTRO_PKGS_SPECS.

that I originally created as the files that I wanted to upgrade for AttackPup (a version of puppy 4) to the latest Kali Rolling Release. See threads:
"Puppy4: How to Remove Built-In Packages from an Extracted SFS"
"[sfs_only]: Attack Pup, Pristine and with Updated Core/CLI libs/utilities"

both of these things would be known by a woof-ce guru
but im not a woof-ce guru

so i will simply be guessing
that would of course take a very long time
but even if i succeeded i would not know what i had done

for example i changed all the yes to no in distro specs
but instead of building an empty iso
it didnt even build an iso

i assume that removing things from distro specs is the key

You can try using the first list I posted abov

Code: Select all

e (of the packages I moved and have those as "yes" and the others as "no" and see what happens. I'm not sure if it will work though because I don't know how ingrained the puppy gui components are.

Edit: The script does not yet move the metadata in DISTRO_PKGS_SPECS or woof-installed packages, so I still have some work to do on it.

[666philb]

i think that one of the main problems to solve with this "modular pup +" is the "builtin_files" list that the package manager uses so as not to install packages twice. Fossapup only has so to speak ... two states, one with the adrv and one without and alters the "builtin_files" accordingly.

with say just 5 switchable modules you would have possible a combination of 30+ different states for "builtin_files".
this problem would exacerbate with added modules.

would need some nifty scripting to do this!

[666philb]

with the woof aspect .... that's just a choice of what remove and keep which in itself presents some problems.

what basics will it have .... gtk2 support? gtk3? audio? what level of graphical support?

[wanderer]

hi s243a and 666phib

thank you very much for all your help

my goal with this part of the community puppy project
is not to build a complete puppy system
just the most minimal base

almost everyone that is interested in fossapup64
will use the full version
even people that want a cut down puppy will use the cut down module

this is just an introduction to woof-ce, fossapup64 and the community puppy
and a base from which to start

my idea is that a non guru will build this base
say to themselves
now i know how woof-ce generally works
and that only took 5 minutes to build
maybe ill add something and see how that goes
over time they will learn more and more
and will become involved with puppy
and feel they are building their own creation
and maybe even learn enough to help with development

a guru will say
this seems like an interesting and simple and useful project
maybe ill make a module or script
and add it to the base and see how that goes

over time more and more modules and scripts will be made
and more and more options will be available
both to gurus and non gurus
and so a community puppy repository will be built
and a community puppy will be made

this project is as much about developing a community puppy project
as it is about developing a minimal modular puppy
the latter just facilitates the former

to start
the only thing necessary to be made are 2 isos

1. an initrd only iso with busybox ash shell
2. a basic x main.sfs file - maybe with xvesa

a window manager and xterm
and eventually a wired and wifi demon
and a browser will need to be available
but i see them as modules so they dont confuse the non guru
as to what is needed for each component

thats the whole project at this stage

everything else should be added slowly by multiple members over time
and kept in the community puppy repository
for use by everyone at their leisure

this part of the project will be kept totally compatible with woof-ce
so that the latest woof-ce can always be used

if a module gets outdated
you can just leave it in the repository
and dont use it in your latest build
someone else may actually want an older module for their build

i have now gotten over my little fit of frustration
and will go back to playing with woof-ce
and try to make the 2 isos i have mentioned

i will try to follow your instructions

i have no deadline
but without help this probably will take a very long time

thanks again

william

[wanderer]

hi all again

i envision the community puppy project
which will be a subproject of woof-ce
to consist of

1. a community puppy module repository
2. a script to build modules - sfs files
3. a build script to assemble isos from the modules in the repository
4. templates (text files) that tell the build script what modules to include in that particular build
so that each build is reproducible modifiable and saved

you can see how simple the whole thing is
and the only things needed to start
are the 2 base isos
everything else should slowly develop from there

william

[wanderer]

just a few things to remind myself

all modules should be sfs files
that way the iso build script and module maker script only need to deal with one type of file

every module should have a unique number (as well as the name)
like m12345-wifi
that way the build script doesnt have to worry about resolving conflicting names

there should be only 4 types of modules
1. bootloader modules
2. kernel modules
3. core modules (initrd and base x main.sfs)
4. extension modules (everything else)
if someone can think of another type of module that is needed
please tell me

remember it is possible to load an sfs file both with a unionfs and with symlinks (which are unlimited)

the main.sfs file should only contain base x
there can be any number of base x sfs files
for example one for xvesa and one for xorg
all other stuff gtk1,2,3, window managers firmware etc should be modules
so you can choose the one you want for that build

there will be only one main community puppy repository
(of course everyone will have their own with a limited set of modules so they dont have to download much)
(and they will then be able to build puppies offline)
the iso build script will choose the modules you want
this way multiple versions of the community puppy can be kept together
and you dont have to have a separate repository for every flavor
if you want 32 bit choose 32 bit modules
if you want a new kernel choose a new kernel module
since each module will be self contained it wont interfere with the others

dont worry about redundancy
and loading the same dependencies again
this will create impossible complexity in the build script
just put the stuff you need for that app in that module
over time groups of modules will emerge that satisfy different criteria
remember it doesnt matter if there is an outdated or redundant module
just dont choose that module for your build

i have a very simple small jwm build - 95k
that only requires 1 config file - corepup-jwmrc
and only xlib
that i use in corepup
i will make an sfs module of this so that we have a very minimal jwm
to use with the base x main.sfs file - just to start

the 2 scripts
can and should be very simple

1. the module maker script
only needs to make things into an sfs file
so you could use uextract to extract it into a folder
and mksquashfs to squash it into an sfs file

2. the iso builder script
only needs to combine everything into an iso
download the modules from the (local or main) repository
put everything in a folder
and use mkiso to make an iso of it
the actual linking of the sfs files
would be done by taersh's initrd
or a script to use mnt -o loop and cp-ias to symlink them to root

[s243a]

I added the ability to create a DISTRO_PKGS_SPECS, for the items that my script moved. Here is my modified script:

Here is the DISTRO_PKGS_SPECS that was generated:

Code: Select all

#w469 fallbacks when looking for pet pkgs.... (note, older: lucid karmic jaunty intrepid)
FALLBACKS_COMPAT_VERSIONS='xenial trusty'

#custom templates=cups,sylpheed,ghostscript,xorg-base

#PKGS_SPECS_TABLE table format:
#will pkg be in puppy-build.
#    Generic name for pkg. Note: PET packages, if exist, use this name.
#            Comma-separated list of compatible-distro pkg(s). '-' prefix, exclude.
#            Must be exact name-only of pkg, else '*' on end is wildcard to search full name.
#            Empty field, then use PET pkg.
#                                    How the package will get split up in woof (optional redirection '>' operator).
#                                    Missing field, it goes into exe. Can also redirect >null, means dump it.
#yes|abiword|iceword,iceword-plugins|exe,dev,doc,nls

#example showing wildcard. finds all full pkg names with 'gcc-4.3*',
#but, exclude any 'gcc-4.3-doc*' matches...
# yes|gcc|gcc,gcc-4.3*,-gcc-4.3-doc*|exe,dev,doc,nls

#110817 Comments preferred to be on end of line, ex:
# yes|abiword|iceword,iceword-plugins|exe,dev,doc,nls| #this is a comment.

#110829 enhancements:
#                                                     Force pkg is from compat-distro repo, specifically 'salix' repo.
# yes|abiword|iceword,iceword-plugins|exe,dev,doc,nls|compat:salix
#Generic format:
# yes|genericpkgname|[pkgnames]|[splitup]|[pet:[repo]]
# yes|genericpkgname|[pkgnames]|[splitup]|[compat:[repo]]
#for a fuller explanation of the entries in PKGS_SPECS_TABLE, please see:
# http://bkhome.org/blog/?viewDetailed=02414

PKGS_SPECS_TABLE='
yes|glibc|libc-bin,libc6,libc-dev-bin,libc6-dev,tzdata|exe,dev,doc,nls
yes|ncurses|ncurses-base,ncurses-bin,libncurses6,libncurses6,libncursesw6,libncurses5-dev,libncurses-dev,libncursesw5,libncursesw5-dev,libtinfo5,libtinfo6,libtinfo-dev|exe,dev,doc,nls
yes|libselinux|libselinux1,libselinux1-dev|exe,dev,doc,nls
yes|libsepol|libsepol1,libsepol1-dev|exe,dev,doc,nls
yes|debianutils|debianutils|exe,dev,doc,nls
yes|coreutils|coreutils|exe,dev>null,doc,nls
yes|grep|grep|exe,dev>null,doc,nls
yes|gmp|libgmp10,libgmpxx4ldbl,libgmp-dev,libgmp3-dev|exe,dev,doc,nls| #in precise, this was only in devx, but abiword needs it.
yes|mpfr|libmpfr6,libmpfr-dev|exe>dev,dev,doc,nls
yes|readline|libreadline8,libreadline-dev,readline-common|exe,dev,doc,nls
yes|libsigsegv|libsigsegv2,libsigsegv-dev|exe,dev,doc,nls
yes|gawk|gawk|exe,dev,doc,nls
yes|sed|sed|exe,dev>null,doc,nls
yes|tar|tar|exe,dev>null,doc,nls
yes|xz|xz-utils,liblzma5,liblzma-dev|exe,dev,doc,nls
yes|liblz4|liblz4-1|exe,dev,doc
yes|lzo2|liblzo2-2,liblzo2-dev|exe,dev,doc,nls
yes|squashfs-tools4||exe|  #note, kernel-version sensitive
yes|gzip|gzip|exe,dev>null,doc,nls
yes|cpio|cpio|exe,dev>null,doc,nls
yes|bzip2|bzip2,libbz2-1.0,libbz2-dev|exe,dev,doc,nls
yes|attr|libattr1,libattr1-dev|exe,dev,doc,nls
yes|acl|acl,libacl1,libacl1-dev|exe,dev,doc,nls
yes|libsystemd|libsystemd0,libsystemd-dev|exe,dev,doc,nls
yes|procps|procps,libprocps8,libprocps-dev|exe,dev,doc,nls
yes|util-linux|util-linux,fdisk,mount,uuid-runtime,bsdutils,libuuid1,libblkid1,libfdisk1,libmount1,libsmartcols1,libfdisk-dev,libmount-dev,libsmartcols-dev,uuid-dev,libblkid-dev,libmount-dev|exe,dev,doc,nls| #ADDED 20150717-08 20150730 20150808
yes|dialog|dialog|exe,dev>null,doc,nls
yes|gettext|gettext,gettext-base,libasprintf0v5,libasprintf-dev,libgettextpo-dev|exe,dev>null,doc>null,nls>null| #MERGED 20150717-08
yes|gcc_dev|gcc-9-base,gcc,gcc-9,g++,g++-9,cpp,cpp-9|exe>dev,dev,doc,nls
yes|gcc_lib|gcc-10-base,libasan5,libatomic1,libgcc-s1,libgcc1,libgcc-9-dev,libgomp1,libisl22,libitm1,libquadmath0|exe,dev,doc,nls
yes|gettext_devxonly|gettext-base,gettext|exe>dev,dev,doc,nls
yes|zlib|zlib1g,zlib1g-dev|exe,dev,doc,nls
yes|file|file,libmagic1,libmagic-mgc,libmagic-dev|exe,dev,doc,nls
yes|devmapper|libdevmapper1.02.1,libdevmapper-dev,libdevmapper-event1.02.1|exe,dev,doc,nls
yes|keyutils|libkeyutils1,libkeyutils-dev|exe,dev>null,doc,nls
yes|kmod|kmod,libkmod2,libkmod-dev|exe,dev,doc,nls
yes|diffutils|diffutils|exe,dev,doc,nls
yes|e2fsprogs|comerr-dev,e2fslibs,e2fslibs-dev,e2fsprogs,libext2fs2,libext2fs-dev,libblkid1,libblkid-dev,libcom-err2,libss2,libuuid1,ss-dev,uuid-dev|exe,dev,doc,nls
yes|findutils|findutils|exe,dev>null,doc,nls
yes|ntfs-3g|ntfs-3g,ntfs-3g-dev,libntfs-3g883|exe,dev,doc,nls| #this seems to have taken over the full functionality of ntfsprogs.
yes|fuse|fuse,libfuse2,libfuse-dev|exe,dev,doc,nls|
yes|expat|libexpat1,libexpat1-dev|exe,dev,doc,nls
yes|parted|parted,libparted2,libparted-dev,libparted-fs-resize0|exe,dev,doc,nls|
yes|libusb|libusb-0.1-4,libusb-dev|exe,dev,doc,nls
yes|bdb|libdb5.3,libdb-dev,libdb5.3-dev|exe,dev,doc,nls
yes|perl|perl,perl-base,perl-modules-5.*|exe>dev,dev,doc,nls
yes|perl-digest-sha1|libdigest-sha-perl|exe,dev>null,doc>null,nls>null
yes|perl-html-parser|libhtml-parser-perl|exe,dev>null,doc>null,nls>null
yes|openssl|openssl,libssl1.1,libssl-dev|exe,dev,doc,nls
yes|ca-certificates|ca-certificates|exe,dev,doc,nls
yes|curl|curl,libcurl4,libidn2-0,libpsl5,libpsl-dev,libnghttp2-14,libssh-4,libcurl4-openssl-dev|exe,dev,doc,nls|
yes|audit|libaudit-common,libaudit1,libaudit-dev|exe,dev,doc,nls| #needed by xorg.
yes|libcap-ng|libcap-ng0|exe,dev,doc,nls|
yes|pam|libpam0g,libpam0g-dev,libpam-modules|exe,dev,doc,nls|
yes|libcap|libcap2,libcap-dev|exe,dev,doc,nls
yes|libcapnp|libcapnp-0.*|exe,dev,doc,nls|
yes|libunistring|libunistring2,libunistring-dev|exe,dev,doc,nls
yes|wget|wget,libpcre2-8-0|exe,dev>null,doc,nls
yes|libmnl|libmnl0,libmnl-dev|exe,dev,doc,nls
yes|iptables|iptables,libxtables12,libnftnl11|exe,dev,doc,nls
yes|libgpg-error|libgpg-error0,libgpg-error-dev|exe,dev,doc,nls
yes|sqlite|sqlite3,libsqlite3-0,libsqlite3-dev|exe,dev,doc,nls
yes|dhcpcd||exe,dev,doc,nls|
yes|wireless-tools|wireless-tools,libiw30,libiw-dev|exe,dev,doc,nls
yes|libnl3|libnl-3-200,libnl-3-dev,libnl-cli-3-200,libnl-cli-3-dev,libnl-genl-3-200,libnl-genl-3-dev,libnl-nf-3-200,libnl-nf-3-dev,libnl-route-3-200,libnl-route-3-dev|exe,dev,doc,nls
yes|dbus|dbus,dbus-x11,libdbus-1-3,libdbus-1-dev|exe,dev,doc,nls|
yes|wpa_supplicant|wpasupplicant|exe,dev>null,doc,nls
yes|pcre|libpcre16-3,libpcre3,libpcre2-16-0,libpcre2-dev,libpcre32-3,libpcre3-dev,libpcrecpp0v5|exe,dev,doc,nls| #MERGED 20150717-08
yes|glib|libglib2.0-bin,libglib2.0-0,libglib2.0-data,libglib2.0-dev,libglib2.0-dev-bin|exe,dev,doc,nls
'

for some reason pastebin flagged this DISTRO_PKGS_SPECS as "offensive" so the output is posted here rather than on pastebin.

The output as noted previously is a CLI module about 33MB. The output can be made smaller by replacing full utilities with busybox. The output doesn't include any Xorg components because I would rather that be a seperate module, which one can merge with this module if they wish. The reason for this to be a CLI only module is that sometimes one wants a pure cli system. Some use cases or a pure cli include, a chroot, a remote shell, or as a base to build a distro up from.

This is my understanding of @wiak's philosophy in weedog/W_LGO or said another way, One can build from a minimal system (perhaps called a rootfsfs) that only has cli components a fuller system using the package manager. As a consequence, I can imagine many use cases where one does not want gui components.

Edit: The above generated DISTRO_PKGS_SPECS, isn't sorted alphabetically. I'm not sure whether this is an issue or not for woof-CE. If it is then I may add sorting ability to my script.

[wanderer]

thank you very much s243a for all your work

in my opinion
the first iso should only include the

1. bootloader - syslinux
2. kernel
3. initrd - busybox only
4. and a main.sfs module with what the initrd copies over

all it needs to do is boot to a busybox ash shell

do you know how to build this in woof-ce

thanks again

william

[Grey]

my idea is that a non guru will build this base

Do you seriously think that "non-gurus" will do something? And this despite the fact that remastering function is already built in. I have some doubts about this. But I understand your aspirations and impulses.

[s243a]

thank you very much s243a for all your work

in my opinion
the first iso should only include the

1. bootloader - syslinux
2. kernel
3. initrd - busybox only
4. and a main.sfs module with what the initrd copies over

all it needs to do is boot to a busybox ash shell

do you know how to build this in woof-ce

thanks again

william

If you just want a busybox shell then why not just grap a copy of a static busybox and create the necessary symlinks. In my opinion that isn't very interesting and puppy does this anyway, in the initrd that it builds.

[wanderer]

hi s243a

when last i manually broke apart puppy and the init file

if the initrd could not find the main.sfs file
it would drop to the busy box ash shell in the initrd
for trouble shooting

that is what we need to start with
the bare minimum

then other things will be added
as sfs files

one can do this by simply manually removing all the sfs files from the iso
but can woof-ce be made to build this

it does not seem very interesting
because it is so simple (intentionally so)
but that is where everything needs to start

minimal modular

william

[taersh]

Who is the target of the new Community Puppy?
To whom will it be addressed?

Geeks, Nerds and Developers?
Or just Users?

If its main target would be just Users, then that minimum base .iso should boot into a graphical desktop and it should have everything related to graphics and audio included. So, that the User simply could extend this Puppy by downloading and installing programs as usual, or even by the use of previously built .sfs modules.

Geeks, Nerds and Developers are already able to create what they want from what ever is provided and what they may find.

[s243a]

hi s243a

when last i manually broke apart puppy and the init file

if the initrd could not find the main.sfs file
it would drop to the busy box ash shell in the initrd
for trouble shooting

that is what we need to start with
the bare minimum

then other things will be added
as sfs files

one can do this by simply manually removing all the sfs files from the iso
but can woof-ce be made to build this

it does not seem very interesting
because it is so simple (intentionally so)
but that is where everything needs to start

minimal modular

william

There appears to be a file in the basesfs called /bin/busybox.list which lists each busybox utility and where said utility should be located in the file system if it isn't replaced by the full utility or puppy specific script. It wouldn't be hard to make a script that looks at this list and moves each item if it is a symlink and otherwise recreates the symlink if it doesn't exist at the specified location.

Without such a list it is possible to use busybox to get the list of which utilities it includes. However, busybox won't tell you which folder to put the symlink in. Both woof-CE and woof-Next have scripts that can create the symlinks based on output from busybox.

[s243a]

Who is the target of the new Community Puppy?
To whom will it be addressed?

Geeks, Nerds and Developers?
Or just Users?

If its main target would be just Users, then that minimum base .iso should boot into a graphical desktop and it should have everything related to graphics and audio included. So, that the User simply could extend this Puppy by downloading and installing programs as usual, or even by the use of previously built .sfs modules.

Geeks, Nerds and Developers are already able to create what they want from what ever is provided and what they may find.

Geeks Nerds and Developers differ in skill level and some of these people we may just call users. It isn't too hard to install most things from a CLI based package manager. Therefore, I think it makes sence to at least understand which components are needed for a CLI based system and which are the additional components need for a minimal gui based system.

Whether the end result is packaged as a single sfs or a split into gui and non-gui based components (two sfs) is inconsequential and shouldn't significantly impact the end user experience.

[wanderer]

hi taersh

the community puppy system will be primarily targeted at users

hoping to introduce them to building puppies
and teach them enough
to possibly even become developers

that is why the system is designed to be so simple

it is all based upon
a simple iso build script
and templates

all a non guru will need to do is
download the iso build script
download a template for a puppy that is of interest
run the build script
and there is the puppy iso of interest ready to use
the iso can be rebuilt and added to / or subtracted from
by simply adding or deleting (commenting out) lines from the template

the non guru can look at each module
and learn what is needed for each component
since each module is isolated and self contained
a great learning experience

gurus can make modules or write clever scripts to do fancy stuff
and maybe that will amuse them

but this is for the community

william

[wanderer]

the problem here

is not building an initrd
that has busybox in it (all busybox symlinks should be in /bin)

the problem is getting woof-ce to do this

remember this is a subproject of woof-ce
and has to remain compatible with woof-ce development

william

[s243a]

the problem here

is not building an initrd
that has busybox in it (all busybox symlinks should be in /bin)

In the base sfs Fossapup64 doesn't put all busybox symlinks in /bin so I don't think we should change this. However, in the intird woof-CE already does put the busybox symlinks in /bin and this is what you want.

the problem is getting woof-ce to do this

Woof-CE already does this so perhaps there is something else you want it to do?

remember this is a subproject of woof-ce

I say only if it is practical to do so. On thing about basing a project on an existing puppy is that an existing puppy already has all the pieces assembled. It might be unecesairlly time consuing to repeat this process (e.g. re-download).

and has to remain compatible with woof-ce development

william

For sure, or at least as much as is possible/practical.

[wanderer]

nothing should be changed in woof-ce
i was just giving my opinion (a joke) on the busybox symlinks

woof-ce should build the initial iso
initrd only busybox ash

and then the next step is to get woof-ce to build the initial basic -x main.sfs file iso

both isos can be placed in the community puppy repository
and new ones built as desired
and also placed in the community puppy repository

the rest is just add on sfs files
also placed in the community puppy repository

the only downloads will be from the community puppy repository
and you will only download what you use
and wont have to download them again
because you will keep them in your local repository

this is the core of puppy
so it should not change much in each iteration of woof-ce
and should be very straightforward to build

taersh's initrd can be added to the puppy community repository as an option
until it is accepted in the main woof-ce master

william

[wanderer]

hi all

well im ready

can someone provide instructions on how to make woof-ce make the first iso

initrd only

william

[wiak]

However, busybox won't tell you which folder to put the symlink in. Both woof-CE and woof-Next have scripts that can create the symlinks based on output from busybox.

I would advise (if not too problematic to do so) using the paths provided by following command:

busybox --list-full

That's what I am using nowadays in WeeDogLinux builds. You can occasionally run into odd issues when simply sticking all symlinks into /bin (or at least I did - though I can't find my notes about that - must have forgotten to add them to my 'cherrytree' memory...). For the most part, it doesn't seem to matter in the initrd/init, but I certainly did run into a problem in WDL initrd/init which above path usage fixed.