Distributions created by Forum members

A home for all kinds of Puppy related projects
Message
Author
User avatar
666philb
Posts: 3615
Joined: Sun 07 Feb 2010, 12:27
Location: wales ... by the sea

#121 Post by 666philb »

anything older than tahrpup and early slacko and you can't use woofce

plus there are already isos which are small for old pups

it should be a modern pup stripped down .. as unicorn was at it's time. even if you built a 217 pup... what use would it be? no online banking, no youtube, no lots of sites, no playing of modern video codecs. the original iso is small anyway so building another is pretty pointless.

i would take peebees upupbionic and then strip all apps at first and see if it works.
and then experiment through trial and error at stripping a few libs (google them and see what they do)
you could even strip all graphic drivers except vesa
and then have an old retro kernel with minimal firmware.

i think you may be able to get down to a 170mb iso possibly smaller (unicorn was 130mb but had all graphic drivers but that was a few years ago now)

you will then have a small barebone modern base puppy that can run modern apps if necessary and also has the possibility of running on new hardware as well as old
Last edited by 666philb on Wed 20 Mar 2019, 16:23, edited 1 time in total.
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331

User avatar
666philb
Posts: 3615
Joined: Sun 07 Feb 2010, 12:27
Location: wales ... by the sea

#122 Post by 666philb »

and wiaks makepup won't work until there's a minimal build recipe.. so the first thing to do is choose a pup that's in woofce (i recommend upupbb or dpup stretch) and then work through my earlier post ... editing their DISTRO_PKG_SPECS (just remove known named apps at the start until you get the hang of it ie .. mpv, deadbeef, abiword, gnumeric etc)

and as said before .. this will require trial and error and also a bit of time. .. but it's a nice project to do if you have the will and time
Bionicpup64 built with bionic beaver packages http://murga-linux.com/puppy/viewtopic.php?t=114311
Xenialpup64, built with xenial xerus packages http://murga-linux.com/puppy/viewtopic.php?t=107331

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#123 Post by rufwoof »

Why do you need a minimal? I have a modern Pup (well EasyOS actually) that is just 23MB. cli only with net connected, tmux, mc, sc-im, calcurse, lynx 'base' system (quite a extensive busybox within that i.e. vi, httpd ...etc.). Download and aufs mount a sfs and its gui/X. Hardware specific i.e. ethernet modules/firmware for my specific kit. I use that as a secondary alternative boot choice i.e. if my primary boot decides not to boot. I also sometimes use it just for a quick boot, for instance to check my calendar/diary, as it boots near instantaneously.
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

sheldonisaac
Posts: 902
Joined: Mon 22 Jun 2009, 01:36
Location: Philadelphia, PA

minimized modern distro

#124 Post by sheldonisaac »

666philb (in part) wrote:it should be a modern pup stripped down .. as unicorn was at it's time.
Ah, thanks, 666philb; I used that.
you will then have a small barebone modern base puppy that can run modern apps if necessary and also has the possibility of running on new hardware as well as old
That would be lovely! I'm an old user, but don't have the ability/motivation to do remastering, etc.
Dell E6410: BusterPup, BionicPup64, Xenial, etc
Intel DQ35JOE, Dell Vostro 430
Dell Inspiron, Acer Aspire One, EeePC 1018P

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#125 Post by musher0 »

Hi wanderer, 666philb and all.

:?: "...a bit of time..." :?:

Using bash's replace function, that should read:

Code: Select all

Q="...a bit of time...";echo "${Q/bi/lo}"
;)

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#126 Post by wanderer »

hi 666philb I will try what you suggest

and

hi rufwoof I am interested in your easyOS example

I will look into both

they are both in the spirit that led me to corepup

smaller faster simpler more flexible = better

wanderer

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#127 Post by rufwoof »

My 'mini' looks somewhat like the attached, but I set the framebuffer resolution to a higher 800x600. With additional modules you can play videos, view pdf's, listen to music (cmus is nice for that IMO), alpine for mail etc. But that would probably bloat it out to 40MB (combined vmlinuz/initrd.gz) due to extra sound modules being needed. tmux/mc ..etc are nice for predominately keyboard usage (laptops), whilst puppy is better suited to predominately mouse usage. tmux/cli is also nice for ssh'ing into other remote boxes.

For the default boot I have it load up calcurse, local weather report (using wttr.in), mc (file manager/text editor), lynx web browser, sc-im spreadsheet, top for process monitoring. I like one window per program and have set F12 to step between them. With tmux however you can split windows down into panes and zoom/unzoom individual panes to maximised/restored. Question of personal preference/taste.

init code inside initrd, which is specific to my hardware (sky2 ethernet) ...

Code: Select all

#!/bin/sh
export TEXTDOMAINDIR=/usr/share/locale #190103
export TEXTDOMAIN=easyinitrd
export OUTPUT_CHARSET=UTF-8
export LC_COLLATE=C #190104 has been removed from /usr/lib/locale/*
export LC_CTYPE=en_US.UTF-8
mount -t proc none /proc
mount -t sysfs none /sys
mount -t rootfs -o remount,rw rootfs /
ln -s /proc/mounts /etc/mtab 2> /dev/null
export PATH="/bin:/sbin"

#190103 need to know what language now using...
[ ! "$INIT_LANG" ] && INIT_LANG=C #precaution.
wkgLANG="${INIT_LANG}"

case "${wkgLANG}" in
 C|en*)
  wkgLANG="C"
 ;;
 ar*|he*|iw*) #arabic, hebrew
  loadfont < /lib/consolefonts/LatArCyrHeb-16.psfu
 ;;
 *) #all european languages...
  #el|ru|uk|be|sr|tg|os|ba|ce|cv)
  loadfont < /lib/consolefonts/LatGrkCyr-8x16.psfu
 ;;
esac
export wkgLANG

gzip -d /lib/keymaps/uk.gz # loadkeys doesn't like compressed)
loadkmap </lib/keymaps/uk

#####

echo "nameserver 192.168.1.2" >/etc/resolv.conf
echo "127.0.0.1 localhost EASYPC18131" >/etc/hosts

# requires /etc/network/interfaces
mkdir -p /etc/network
echo "auto lo" >/etc/network/interfaces
echo "iface lo inet loopback" >>/etc/network/interfaces
echo "#auto eth0" >>/etc/network/interfaces
echo "#iface eth0 inet dhcp" >>/etc/network/interfaces
echo "iface eth0 inet static" >>/etc/network/interfaces
echo "address 192.168.1.4" >>/etc/network/interfaces
echo "netmask 255.255.255.0" >>/etc/network/interfaces
echo "network 192.168.1.0" >>/etc/network/interfaces
echo "broadcast 0.0.0.0" >>/etc/network/interfaces
echo "gateway 192.168.1.2" >>/etc/network/interfaces
echo "dns-nameservers 192.168.1.4 192.168.1.2" >>/etc/network/interfaces

mkdir -p /var/run/network # needed by ifup
# dmesg on my system indicates sky2 for Ethernet
modprobe sky2 
ifup eth0
/etc/net/dhcp-dns		# dns

localedef -f UTF-8 -i en_US en_US.UTF-8

export LANG=en_US.UTF-8
export LANGORG=en_US.UTF-8

# tmux requires pseudo terminals, but that does open up security weakness
mount -t devpts non /dev/pts -o ptmxmode=0666,newinstance
# new instance is optional, not really required to create a new instance
# to hide from other users on a single user setup
while :; do
	/bin/busybox sh -c '/bin/twin' # twin is my script to launch/setup tmux
done
Attachments
s.png
(161.79 KiB) Downloaded 398 times
[size=75]( ͡° ͜ʖ ͡°) :wq[/size]
[url=http://murga-linux.com/puppy/viewtopic.php?p=1028256#1028256][size=75]Fatdog multi-session usb[/url][/size]
[size=75][url=https://hashbang.sh]echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh[/url][/size]

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#128 Post by wiak »

666philb wrote:and wiaks makepup won't work until there's a minimal build recipe.. so the first thing to do is choose a pup that's in woofce (i recommend upupbb or dpup stretch) and then work through my earlier post ... editing their DISTRO_PKG_SPECS
As you know, makepup wouldn't work at the moment anyway, though plans are afoot to fix it up again. When it is working, it is perfectly possible to use it in a similar manner to what you describe. In its Advanced Options it has a checkbox to pause its otherwise desired unattended build process at various stages, and particularly for when the user wishes to edit DISTRO_PKGS_SPECS before continuing.

But straight woof-CE build scripts are fine to use (except being a bit too interactive for my wishes). Hopefully that woof-CE woof_gui script you mentioned, which I did look at once upon a time, helps new users a bit. I mainly wrote makepup because I wanted to see if I could, and thought it would provide some others with an easy intro to woof-CE world, which I think it did.

Like wanderer, I would also like to see a very basic pup build recipe being made available, but even more drastic in being only the boot system into a terminal, but with sc0ttman's dependency-resolving package manager included and a commandline-driven quickpet type app to install X, a window manager, a browser and whatever as and when desired. Even one that just had X and terminal and pkg and quickpet kind of GUI app would be nice alternative to commandline start only (since newusers might hate commandline...). And I'd really also like specially built small-compiled app repos for it, rather than Debian/Ubuntu/Slacko bloat. That's always been a reason I've kept interest also in Tiny Core, Slitaz, and now Void - I'm impressed by their tiny compiled apps and flexible app compile/creation facilities (Void Linux package manager particularly impressive in these respects, so would love a Void Pup to appear, or a VoidDog for that matter).

wiak

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#129 Post by wanderer »

i am thinking if i can get woof-ce to build a minimal iso

that can accept sfs files and pets

then these will be how whatever apps you need
(desktops firefox vlc etc) are loaded

like pupngo

very small core

endless number of additions

wanderer

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#130 Post by s243a »

wanderer wrote:i am thinking if i can get woof-ce to build a minimal iso

that can accept sfs files and pets

then these will be how whatever apps you need
(desktops firefox vlc etc) are loaded

like pupngo

very small core

endless number of additions

wanderer
It sounds like you just might want petget (or the newer command line alternative) and whatever dependencies that it has.

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#131 Post by s243a »

wiak wrote:
666philb wrote:and wiaks makepup won't work until there's a minimal build recipe.. so the first thing to do is choose a pup that's in woofce (i recommend upupbb or dpup stretch) and then work through my earlier post ... editing their DISTRO_PKG_SPECS
As you know, makepup wouldn't work at the moment anyway, though plans are afoot to fix it up again. When it is working, it is perfectly possible to use it in a similar manner to what you describe. In its Advanced Options it has a checkbox to pause its otherwise desired unattended build process at various stages, and particularly for when the user wishes to edit DISTRO_PKGS_SPECS before continuing.

But straight woof-CE build scripts are fine to use (except being a bit too interactive for my wishes). Hopefully that woof-CE woof_gui script you mentioned, which I did look at once upon a time, helps new users a bit. I mainly wrote makepup because I wanted to see if I could, and thought it would provide some others with an easy intro to woof-CE world, which I think it did.

Like wanderer, I would also like to see a very basic pup build recipe being made available, but even more drastic in being only the boot system into a terminal, but with sc0ttman's dependency-resolving package manager included and a commandline-driven quickpet type app to install X, a window manager, a browser and whatever as and when desired. Even one that just had X and terminal and pkg and quickpet kind of GUI app would be nice alternative to commandline start only (since newusers might hate commandline...). And I'd really also like specially built small-compiled app repos for it, rather than Debian/Ubuntu/Slacko bloat. That's always been a reason I've kept interest also in Tiny Core, Slitaz, and now Void - I'm impressed by their tiny compiled apps and flexible app compile/creation facilities (Void Linux package manager particularly impressive in these respects, so would love a Void Pup to appear, or a VoidDog for that matter).

wiak
What if we just chroot into an existing puppy base sfs, un-install stuff and then repack it as an ISO? I suggest first removing as much x stuff as we can and still have petget work and then keep this version as a reference, with petget you can also remove stuff via the command line so you could remove stuff further this way to get a purely command line version, however at this point it might be better to replace the package manger with sc0ttman's version. The idea here is now to remove the rest of the Xorg related stuff to create a purely command line version of puppy. A lot of puppy tools might require a GUI but if the GUI functionality can be provided with an sfs then one can mount the sfs do the necessary config and then unmount it. One could compare a command line version of puppy with a minimal graphical version and compare the files on each to see what said sfs would be composed of.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#132 Post by wiak »

s243a wrote: What if we just chroot into an existing puppy base sfs, un-install stuff and then repack it as an ISO? I suggest first removing as much x stuff as we can and still have petget work and then keep this version as a reference, with petget you can also remove stuff via the command line so you could remove stuff further this way to get a purely command line version, however at this point it might be better to replace the package manger with sc0ttman's version. The idea here is now to remove the rest of the Xorg related stuff to create a purely command line version of puppy. A lot of puppy tools might require a GUI but if the GUI functionality can be provided with an sfs then one can mount the sfs do the necessary config and then unmount it. One could compare a command line version of puppy with a minimal graphical version and compare the files on each to see what said sfs would be composed of.
The problem with remastering (and what you are describing s243a is as I'm sure you realize a form of remastering) is that it is difficult to end up with a recipe that can be used again once distros change/get upgraded). Woof-CE is designed with the idea of providing a vehicle for repeatability once a compatible 'recipe' has been produced for it. In any case, it seems to be very difficult to whittle down a distro without breaking it - fact is, lots of drivers/modules/firmware is required (and sizable amounts of it) if the distro is to be expected to work on the huge diversity of computers out there. It's also tricky knowing which libs can be 'safely' removed without breaking the system. If it's a build based on Debian/Ubuntu then the person hacking it down has to be well aware of what packages libs can be found in (and it may be more than one lib in one package - I don't know...). Hacking down via remastering like that was something forum member saintless was particularly good at - that was in the early days of his initial DebianDog creation prior to debootstrap being used (as done since by Fred) - but Fred probably has a pretty good idea about hacking down Debian-based systems (and saintless did post some advice about what to keep and what could be safely removed). Big job, tricky job despite it sounding quite simple at first though I'd say. Maybe a list of every component Slitaz or Tiny Core Linux use in their smallest offerings and try and assemble the same for Puppy (but as I say Debian packaging may not allow such fine grained assembly).

wiak

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#133 Post by s243a »

wiak wrote:
s243a wrote: What if we just chroot into an existing puppy base sfs, un-install stuff and then repack it as an ISO? I suggest first removing as much x stuff as we can and still have petget work and then keep this version as a reference, with petget you can also remove stuff via the command line so you could remove stuff further this way to get a purely command line version, however at this point it might be better to replace the package manger with sc0ttman's version. The idea here is now to remove the rest of the Xorg related stuff to create a purely command line version of puppy. A lot of puppy tools might require a GUI but if the GUI functionality can be provided with an sfs then one can mount the sfs do the necessary config and then unmount it. One could compare a command line version of puppy with a minimal graphical version and compare the files on each to see what said sfs would be composed of.
The problem with remastering (and what you are describing s243a is as I'm sure you realize a form of remastering) is that it is difficult to end up with a recipe that can be used again once distros change/get upgraded). Woof-CE is designed with the idea of providing a vehicle for repeatability once a compatible 'recipe' has been produced for it. In any case, it seems to be very difficult to whittle down a distro without breaking it - fact is, lots of drivers/modules/firmware is required (and sizable amounts of it) if the distro is to be expected to work on the huge diversity of computers out there. It's also tricky knowing which libs can be 'safely' removed without breaking the system. If it's a build based on Debian/Ubuntu then the person hacking it down has to be well aware of what packages libs can be found in (and it may be more than one lib in one package - I don't know...). Hacking down via remastering like that was something forum member saintless was particularly good at - that was in the early days of his initial DebianDog creation prior to debootstrap being used (as done since by Fred) - but Fred probably has a pretty good idea about hacking down Debian-based systems (and saintless did post some advice about what to keep and what could be safely removed). Big job, tricky job despite it sounding quite simple at first though I'd say. Maybe a list of every component Slitaz or Tiny Core Linux use in their smallest offerings and try and assemble the same for Puppy (but as I say Debian packaging may not allow such fine grained assembly).

wiak
You could write a script to automate which packages you are removing and than it is repeatable. I think the syntax for petget is something like:

Code: Select all

petget -pkg_name
to remove packages. As for debian; it is the case that debootstrap gives us a minimal debian distribution, granted without the Xorg stuff. So one could have the output of debootstrap as the base image, and then add enough Xorg stuff to run some desired application running Some examples of what one might try to get running include: a web browser, a window manager / desktop, a text editor like geany, or a remote desktop via something like VNC.

If you pick only one graphical application to try to get working then apt-get will install what you are missing and then you should have a good base of Xorg stuff to figure out what you are missing for any puppy tool you want. I know that you might not need everything that "apt" gives you but it's a starting point. Also I thought you were looking for something leaner than debian binaries.

P.S. If you forget which packages you removed you can simply compare your /root/.packages folder to a non-modified release. Ideally one would sort the order of removal so we remove first only packages which nothing else depends on.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#134 Post by wiak »

s243a wrote:As for debian; it is the case that debootstrap gives us a minimal debian distribution, granted without the Xorg stuff. So one could have the output of debootstrap as the base image, and then add enough Xorg stuff to run some desired application running Some examples of what one might try to get running include: a web browser, a window manager / desktop, a text editor like geany, or a remote desktop via something like VNC

...Also I thought you were looking for something leaner than debian binaries.
Yes, if you use debootstrap then really you are just re-inventing the current DebianDog wheel. For Debian/Ubuntu there is no point IMO - instead, just use one of the Dogs - since that is what it is: a Debian puppylookalike based on debootstrap and using apt/dpkg for its package manager. Truthfully, Puppy Debian/Ubuntu systems, as saintless clearly once said, have no advantage over Debian live based Dogs.

The reason I talked about Debian is that most recent Pups do in fact use Debian or Ubuntu repos, but yes, I feel that these are too large compiles with too many dependencies in the chosen compilations. Rather I would like to see a minimal pup system (which uses pup kernel and system components, not Debian or Ubuntu), then on top of that use sc0ttman's pkg to add packages from a repo that is built with small, less dependent compiles - maybe Void Linux repos would fit that model (I'm not sure) or maybe there would be a way of using Slitaz repos or something (but maybe not enough packages there or packages which are limited - I'm not judging...).

But otherwise, yes, I agree, a script that keeps track of everything you did might work, but from what larger iso would you chop things - you only have Debian/Ubuntu/Slackware pups nowadays... Though of course you can script a distro starting with just Puppy system stuff followed by adding things using a suitable package manager and small compile repo (but is sc0ttman's pkg able to use alternative repos than Ubuntu/Debian/Slackware? - I'd be surprised really since it is designed around modern puppy needs so I'd imagine uses Puppy Package Manager type setup/system config files which are designed for use with Debian, Ubuntu or Slackware only maybe???; EDIT: package management is really complicated of course - all such repos have different formats for how things are stored so the package manager has to know about these formats... hence my more than doubts pkg could do this without significant code changes to it, but I'm just surmising).

EDIT2: The reason I mentioned Void Linux, and why I'm myself currently interested in it, is that it does have its own independent package manager/compiling build system called XBPS I think. So if void repos were small and good enough that could be used on top of a tiny Puppy boot system. The result would not be void linux, it would be a puppy but with void linux package management and void packages - not like Tazpup with Slitaz, which only starts as Puppy but really drives normal Slitaz once it gets going (I do like Tazpup a lot though, it's normal slitaz but with Puppy save options etc, which is a huge bonus). No, this would be more like BionicPup say, but with void repos and using void package manager rather than modifed pkg or petget to fetch the desired void packages.

wiak
Last edited by wiak on Thu 21 Mar 2019, 09:24, edited 1 time in total.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#135 Post by wiak »

Following on from my immediate above post:

Note that a VoidDog, would be built in a different way to the VoidPup I described. A VoidDog built the way early DebianDog was built would start with a normal Void Linux install and simply cut it down to the required barebones you like and then make it look and feel like a Pup (though if fredx181 got his hands on it, he would likely actuall use Porteus boot method... if such proved possible). That wouldn't use Puppy boot up system at all, so not really a pup... rather it would be a cut-down actual Void Linux, but puppified. It would be nice to see both, but making a VoidDog would be much easier to implement I feel, whereas we'd like a new Pup too... I'd like a Void Dog too (especially if it could have Porteus boot) and I've actually suggested that to Fred a few days ago (knowing he's far too up to the ears 'too much on his plate' already of course).

Like wanderer I'd really like so see this mythical small pup, similar to pups of old, but so much dev time seems to be used making fixes and tidying up existing woof-CE code endlessly - trying to add actual new distro repo/ woof-CE script handling for the new base system to woof-CE code would certainly seem to me to be a nightmare. So maybe woof-CE is stuck with Ubuntu/Debian Slackware unless major coding additions - which could go on endlessly (as it seems to do). Using sc0ttman's pkg as part of woof-CE code package handling would be a huge advantage to what is there, because of dependency resolution possibility, but would otherwise still be the same woof-CE in terms of Ubuntu/Debian/Slackware woof-CE code, without tons of modification (lots of other distro types seem to have been stripped out of woof-CE over time - Trisquel and Devuan - presumably because becoming bloated and too hard to handle all the different cases. But I don't know - Devuan a type of Debian, so maybe woof-CE can still handle that easily enough at least). For the Debian-like distros, debootstrap is the way to go though... simple and easy to program distros with that - as Fred has shown with newer Dogs (mklive-stretch for example).

wiak

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#136 Post by wanderer »

hi all

i think corepup/tinycore would be a good place to start

it already does everything we are talking about with ease

we could look at the core

and make a puppy version of it

maybe find correlates in woof-ce distro specs

then look at the tcz that make up the basic x system

then look at the tcz that make up the apps
(firefox vlc viewnior etc)

dcore downloads and packages apps from debian

so that is the next step to look at

its easy to symlink an unsquashed 2fs image on a usb

to tinycore as a save file for usb like puppy has

the normal save file (home) for corepup/tinycore
is on the hard drive like puppy

by having a script that changes the names
of the save files (home and tce)
you can make multiple versions
that you can access at will

etc etc etc

i have actually figured out a lot of cool stuff with corepup

so we will start with a completely functional and supported system
and only will need to puppify it

oh and make a simple script to automate the build process
so it can be replicated

i will start to look into that now

wanderer

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#137 Post by wanderer »

hi all

so now i am looking at what is in corepup core
and comparing it to woof-ce distro specs
to get an idea of what to leave marked "yes"
to give a small working core

1st step

wanderer

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#138 Post by s243a »

wiak wrote: trying to add actual new distro repo/ woof-CE script handling for the new base system to woof-CE code would certainly seem to me to be a nightmare. ...(lots of other distro types seem to have been stripped out of woof-CE over time - Trisquel and Devuan - presumably because becoming bloated and too hard to handle all the different cases. But I don't know - Devuan a type of Debian, so maybe woof-CE can still handle that easily enough at least). For the Debian-like distros, debootstrap is the way to go though... simple and easy to program distros with that - as Fred has shown with newer Dogs (mklive-stretch for example).

wiak
I think that Woof can handle Devuan. I believe their is a Devaun pup. Anyway, there is an alternative to adapting woof to handle a different type of repo. The alternative is to write a program to turn said alien repo into a puppy repo. This could be done with non puppy tools. Their are two downsides though, which are maintaining the repo (i.e. handling updates) and have the server resources to host the repo.

Maintenance could to a degree be automated. However, if the alien distro relies on complex scripts to install, remove or re-install a package then this approach could be buggy. However, the conversion tool could have a list of post-install and un-install scripts to swap out for the ones in the alien repo. These would be developed over time as bugs are discovered.

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#139 Post by wanderer »

rufwoof

how did you do your easyOS system

wanderer

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#140 Post by wanderer »

it would be great if the minimal woof-ce
could use all of the tons of puppy sfs and pets already made

a script to make them usable in woof-ce min ?

wanderer

Post Reply