Alternative way to build Ubuntu / Debian Puppy [RETIRED]

Under development: PCMCIA, wireless, etc.
Message
Author
jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

Alternative way to build Ubuntu / Debian Puppy [RETIRED]

#1 Post by jamesbond »

Update 8 Oct 2015.

This project is now retired.

The purpose of this project is to bring fun back to puppy building (along with exploring different ideas); during the time that woof-CE development seemed stagnant.

Woof-CE has just seen a resurgence of activity; and a lot of things have been improved. Maintaining a separate branch of Woof-CE (and trying to sync between them) by myself is not something that I can do concurrently with my other projects (hobby and paid).

Therefore I have decided to retire this project. I have just done one final update (updating the repo-url) so that it should still work; but remember you are on your own. Please feel free to experiment with it, fork it, improve it etc.

I may revert my decision and re-activate this if I get enough feedback and contributions - but I don't hold my breath. Until then, this is it.

So long and thanks for all the fish.

PS: The build system which is the core of Woof-CE NG will live along elsewhere in another project called "Fatdog-Like".

jamesbond signing off.

===== Original post follows =====

Presenting an alternative way to build Puppy Linux from Ubuntu/Debian base distros.
As previously discussed http://murga-linux.com/puppy/viewtopic. ... 293#780293.

What's different between this and standard Woof2 build? This one builds Ubuntu/Debian directly from their native packages, except packages they don't have (e.g. Xdialog, gtkdialog). Hopefully, this way, it will be more compatible than standard Woof2-build puppy. The packages installed is registered with dpkg and can be listed/uninstalled by dpkg.

There are a lot more features, but features aren't the goal. Making it easier to build puppy is - so I'll stop talking about features, discover it yourself and ask if you're confused.

Get the code from here - switch to "deb-build" branch: https://github.com/jamesbond3142/woof-CE/tree/deb-build

How to use:
-----
1. You need to have a fully working "dpkg" package installation in your host system: you need at least "dpkg" and "dpkg-deb". I tested with the full dpkg, I don't know whether it will work with busybox's dpkg.

2. Run merge2out as usual. Choose x86 and x86 (that's the only thing supported at the moment); the rest of the options doesn't matter.

3. cd to the output directory created by merge2out.

To create 32-bit Tahr build:
./deb-build.sh

To create 64-bit Thar build:
ARCH=amd64 ./deb-build.sh

To create 32-bit Unicorn build:
VERSION=utopic ./deb-build.sh

To create 64-bit Unicorn build:
ARCH=amd64 VERSION=utopic ./deb-build.sh

To create 32-bit Debian Sid build:
REPO_URL=http://ftp.au.debian.org/debian REPO_PKGDB=Packages.xz VERSION=sid ./deb-build.sh

To create 64-bit Debian Sid build:
ARCH=amd64 REPO_URL=http://ftp.au.debian.org/debian REPO_PKGDB=Packages.xz VERSION=sid ./deb-build.sh

and so on.

This will download the package database, read "ubuntu-pkglist" and install packages listed there (including dependencies), and build puppy.sfs in "iso/iso-root".

4. Then build an experimental iso by running ./build-iso.sh.
This will fetch Fatdog64's kernel and kernel modules from ibiblio, and complete the contents of "iso/iso-root" and build puppy.iso in "iso".

The iso should be good enough for testing with qemu and virtualbox.

What you can do with the iso?
-----
The iso will boot to a command line (pfix=nox). There is only minimal packages included in the ISO, they are mainly shell, command line utilities, Xorg, jwm, rox-filer, urxvt and mtpaint for testing. For 32-bit builds, there is also Xdialog and gtkdialog that I took from Slacko 5.7. For 64-bit builds, I took Xdialog and gtkdialog from Fatdog64 631.

Once you boot the iso, you may want to run "jwm_menu_create" to fix jwm's menus (you cannot do "fixmenus" as it is missing a tool which is needed for its work, jwm-xdgmenu)). Then start desktop by typing "xinit" (don't use xwin, it doesn't work yet). If you're lucky will be presented with the first-setup screen, quickly quit from that because it't not working (I haven't tested). To quit the graphical desktop, open terminal and then "kill X" or "logout" from jwm menu.
To shutdown, type "poweroff" - but you must kill leave the desktop first. When shutting down, you will be presented with the usual save gui/cli - be warned I have not tested whether it works.

5. Once you're familiar with the build, you may want to look at ubuntu-pkglist. This file contains the list of packages that will get into the build. The comments inside should be pretty explanatory.

Important Note:
1. This is meant for puppy builders.

2. It does *NOT* build a working puppy as you know it. Still needs work in terms of adding the correct packages, minimising the build (deleting unnecessary stuff), and obviously, fix the brokenness.

3. The kernel used is 64-bit kernel from Fatdog64, thus the sample code will not run on 32-bit machines unless you change the kernel (just replace vmlinuz and kernel-modules.sfs in iso/iso-root and re-run build-iso.sh). The kernel you compiled must contain enough drivers to access and load kernel-modules.sfs - usually this means filesystem drivers, usb drivers and keyboard drivers must be compiled in. If you don't like this, feel free to build initrd in the usual way (putting modules in initrd and rootfs) - as for me, I find that it is very clean to put *all* kernel modules in zdrv. This way, to upgrade kernel is trivial - replace vmlinuz and kernel-modules.sfs with a new one.

Mini-FAQ
----------
1. Q: Got this. How to keep the size down?
A: - Look at /var/lib/dpkg/info; this has the list of installed packages. %remove unnecessary ones.
- Look at rootfs-skeleton/pinstall.sh. This file is run at the end of puppy-base installation; use it to remov unnecessary files

2. Q: I want to build from Slackware (or RPM, or Arch, or packdude, etc)
A: This script only builds from Debian. A similar one can be written for all the above, perhaps we can then write a new front-end that will call these build scripts depending on what distro you use.

3. Q: Many of Puppy utilities don't work!
A: Certainly, because many of the dependent packages are missing. Add them and they *may* work.

4. Q: Puppy base is incompatible with Ubuntu/Debian in many aspects. You missed a lot of the "adaptation" already there in Woof2 scripts to make it work with Ubuntu/Debian base.
A: I think this is not the way to move forward. Rather than adapting Ubuntu/Debian/Slackware/CentOS - whatever parent distro - to Puppy, we should do the other way: adapt Puppy script to run with whatever the parent distro is. This way, we modify as little as possible from the parent distro and thus the rest of the packages from parent distro are more likely to work (which is the reason *why* we want to build from a parent distro).

5. Q: So many commits. What has changed between this and the original Woof-CE?
A: boot/initrd-tree0 - two-line changes, and rootfs-skeleton/pinstall.sh. Everything else is pristine. I do plan to make more changes later, but I want so show that even with plain Puppy base, it works.

This is a work in progress. Suggestions and improvements welcome. Do not expect a Puppy release by me - this tool is for puppy builders and they will be the one releasing puppies, not me.

Enjoy.

EDIT: editorial changes.
EDIT: update - now with jwm menus shown properly, icons shown properly.
EDIT: add Xdialog and gtkdialog for 64-bit builds too.
Last edited by jamesbond on Thu 08 Oct 2015, 10:37, edited 5 times in total.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#2 Post by jamesbond »

Reserved.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#3 Post by Iguleder »

Cool! Gonna play with this once I finish my current work.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#4 Post by 01micko »

Slacko64 has dpkg and dpkg-deb so I'm trying a 64 build now. :P (although dpkg is bb version.. dpkg-deb is full).

EDIT: seems to be working, the chroot tree looks sane so far...

EDIT: FAIL.. busybox dpkg can't recognise "--root=" option.

EDIT: lazy me just installed precise dpkg with libselinux1 :P . I have an sfs

EDIT: booted (on real hardware, nomodeset, and I remind you built on slacko64, ubuntu dpkg, copied gtkdialog & Xdialog straight out of running OS with a hack to make_sfs() and 3 packages out of 273 failed - apart from gtkdialog/Xdialog) straight to desktop. Amazed. I'm having a beer too so PEBKAC is of high probability why keyboard and mouse don't work! I have to add NOX as a param, but I thinks that is failing since BK reworked xorg. I'll try it (booting from grub4dos).

EDIT: pretty much works now except dhcpcd isn't there and saving session is broken. Probably a binary missing to probe partitions or something like that.
Puppy Linux Blog - contact me for access

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#5 Post by mavrothal »

01micko wrote: I'm having a beer too so PEBKAC is of high probability why keyboard and mouse don't work!
I can testify that beer is not causing the failure of keyboard/mouse :lol:

BTW pinstall is missing the dash in "cp --remove-destination"
also the mksquashfs parameters are not parsed correctly (in Lubuntu 14.04)
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#6 Post by 01micko »

mavrothal wrote:I can testify that beer is not causing the failure of keyboard/mouse :lol:
Actually have it working now.. was PEBKAC so there! :twisted:
Puppy Linux Blog - contact me for access

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#7 Post by mavrothal »

01micko wrote:
mavrothal wrote:I can testify that beer is not causing the failure of keyboard/mouse :lol:
Actually have it working now.. was PEBKAC so there! :twisted:
Do tell
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#8 Post by 01micko »

Ensure you boot to NOX... I didn't add pfix=nox to my menu.lst and that's why it failed. NOX is broken but once you get back to prompt, delete /etc/X11/xorg.conf and run "xinit" it's all good.. until the next hurdle (I did another quick build and added dhcpcd, dragged in some stuff).

Then apt fails. need to configure /etc/apt/sources.list with a repo.. and damn.. my bandwidth for the month just run out! Taking ages to get the list from aarnet.edu.au. So it might well be tomorrow before I'm running virtualbox on this thing :lol:
Puppy Linux Blog - contact me for access

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#9 Post by jamesbond »

Thank you guys for the interest!
mavrothal wrote:BTW pinstall is missing the dash in "cp --remove-destination"
Ta - fixed.
also the mksquashfs parameters are not parsed correctly (in Lubuntu 14.04)
I'm using Xcompression-level 1 to speed up squashing. It's new parameter only available in recently released squashfs-tool 4.3 (kirk found about it). Comment out that parameter and you should be golden (I will comment it out too and the commit it to github).
01micko wrote:3 packages out of 273 failed
Two of that 3 would probably be xdialog and gtkdialog. I haven't packaged 64-bit xdialog and gtkdialog - don't have slacko64 around handy. Now that I think about it, perhaps I should just take Fatdog's xdialog/gtkdialog and see if the dependencies are satisfied. If it does, I can pack it out.

EDIT: I have now packaged Fatdog's Xdialog and gtkdialog. Fatdog's gtkdialog is older (0.8.3) than Slacko's one (0.8.4).
NOX is broken but once you get back to prompt, delete /etc/X11/xorg.conf and run "xinit"
Yes, xwin is "broken" (let's just say, not compatible with the recent Xorg here). I am tempted to replace it with Fatdog's xwin, but that's putting the cart before the horse - since here we are talking about "build system" rather that the puppy-base (if you're talking about the puppy-base, there is ton I'd like to replace :twisted:)

Remember, if you want to see familiar jwm menus, please run jwm_menu_create before starting xinit.
hen apt fails. need to configure /etc/apt/sources.list with a repo.
Yup - it's not configured yet. I haven't found a reliable way to configure it automatically when you can build from so many sources. I included apt-get mainly to test/show that "apt list" works for packages installed by the build system. I'll think of something.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#10 Post by 01micko »

Just added firefox to my package list

Postiing from it now...
jamesbond wrote:Two of that 3 would probably be xdialog and gtkdialog. I haven't packaged 64-bit xdialog and gtkdialog - don't have slacko64 around handy. Now that I think about it, perhaps I should just take Fatdog's xdialog/gtkdialog and see if the dependencies are satisfied. If it does, I can pack it out.
No, I accounted for those; with them I had 5 failures. I couldn't figure them out as it went past the buffer of lines in rxvt and I couldn't scroll up. A very simple logging system might be helpful. Besides I haven't much time but I couldn't resist this :roll: :lol: . I'll be of more use after next Thursday.
Attachments
shot.jpg
(85.31 KiB) Downloaded 2750 times
Puppy Linux Blog - contact me for access

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#11 Post by mavrothal »

Hi James,
I finally had the chance to look at the code a bit (instead of just use it :oops: ).
Since you have branched out of master the deb-build.sh ignores woof-CE/woof-code/rootfs-packages/ which is currently in testing. It would be handy to include since there puppy pets, usually from the noarch or common repo and almost ubiquitously used in puppies, can be placed to improve puppy experience when building from deps, rpms etc.
The expected format in rootfs-packages is woof-CE/woof-code/rootfs-packages/package_name/{<tree>,pinstall}. Ideally inclusion of rootfs-packages should be optional (or even package specific) in case someone wants to build with official packages only. Eventually some of the rootfs-skeleton packages (like petget or pup_event) could also be moved to rootfs-packages.
Alternatively, deb-build.sh, could also pull pets (from a respective list), though I think rootfs-packages could be better controlled to be consistent and distro independent.
Of course implementing both would be another option :shock: :D
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#12 Post by jamesbond »

Updated. deb-build.sh now supports installing from rootfs-packages.

01micko:
- sources used to build the distro now recorded in /etc/apt/sources.list.d, so apt-get works out of the box (you still need to install gnupg) - I tested with apt-get update
- to log output from deb-build.sh, do "./deb-build.sh 2>&1 | tee build.log"

Note:
%puppy renamed to %addbase
to install rootfs-packages, use %addpkg
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#13 Post by 01micko »

Thanks. Just did an update. The failed packages are:

Code: Select all

Cannot find xorg-input-abi-20.
Cannot find perlapi-5.18.1.
Cannot find xorg-video-abi-15.
Cannot find python3:any.
The last one is for firefox. None (of the missing pkgs) seem to have a detrimental effect.

EDIT: now that apt is working they all instaaled automagically... in no time.
Puppy Linux Blog - contact me for access

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#14 Post by jamesbond »

01micko wrote:Cannot find xorg-input-abi-20.
Cannot find perlapi-5.18.1.
Cannot find xorg-video-abi-15.
Yeah, these ones are odd. They are listed in the database, not no reference how to get them. Perhaps they are in trusty-updates or other.
Cannot find python3:any.
Apparently this is a new format on dpkg format. I should strip anything after a colon ... lemme check.

Anyway, just pushed an update. Apt-get now works out of the box if you include the apt-database (WITH_APT_DB=1 ./deb-build.sh). If not, when running, you need to "apt-get update" first. It's good enough for me to be able to install firefox through it. Synaptic, unfortunately, requires gtk3 :evil:
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#15 Post by Iguleder »

Looks good. I really wonder how big it is with all Puppy applications, before cleanup.

Also, rootfs-skeleton is a mess. It clutters the main SFS with so many files.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#16 Post by mavrothal »

Iguleder wrote:Looks good. I really wonder how big it is with all Puppy applications, before cleanup.
With firefox is ~170MB (gzipped SFS) Abiword/Gnumeric and friends pulls a lot more though.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#17 Post by jamesbond »

mavrothal wrote:
Iguleder wrote:Looks good. I really wonder how big it is with all Puppy applications, before cleanup.
With firefox is ~170MB (gzipped SFS) Abiword/Gnumeric and friends pulls a lot more though.
That's because Abiword and Gnumeric depends on GTK3 :evil: So for these kind of apps, you need to build GTK2 versions and package them into DEB and upload to own repo. And you can bump up the compression by using "-comp xz -Xbcj x86" instead of the default "-comp gzip" I have in my sample pkglist. It will still be big, though.

Another trick is this - you can attempt to turn off dependency (%nodepend) and install the package and its dependencies manually, with you choosing only the deps you want to install (this is no fun, but works). Or, you can keep dependency checking on, but later you %remove the packages that you don't need. Some of the dependencies are really not needed (e.g. udev pulls a crap load of dependency, which I ignore with %nodepend, and it still works).

Of course, the success of this depends on the package itself. With some packages, the depedencies are really with loadable modules/plugins - if you don't include the dependencies, those plugins won't work but the main application still work. Some packages, however, have dependencies compiled built into them - with these kind of packages you're really out of luck.

With abiword/gnumeric which depends on gtk3, you don't really have an option other than pulling all those gtk3 stuff :? I'd recommend making our own DEBs for these as they are not core to the system. (Xorg, however, is core, and we should keep parent distro's one).
indicative only wrote:# grep systemd repo-trusty-i386/pkgdb | wc -l
58
# grep libgtk-3 repo-trusty-i386/pkgdb | wc -l
540
# grep libgtk2 repo-trusty-i386/pkgdb | wc -l
1329
I'm very troubled with the fact that synaptics depends on gtk3, I hope there is a way to build it to depend on gtk2. Aptitude-gtk is dead, and aptitude-ncurses depens on .... python?! Any other GUI front-end to apt? :?
Also, rootfs-skeleton is a mess. It clutters the main SFS with so many files.
:lol:
Don't like it? Here's a trick: Mavrothal asked me to add support for installing rootfs-packages, which I did. I now have another purpose for that "rootfs-packages" - how about we make a package called "myown-rootfs", and in the pkglist we don't do %addbase but instead to "%addpkg myown-rootfs" :twisted:
I had an example called james-mods which replaced xwin with a simpler variant, and replaces xorg-wizard, but nothing is stopping you to supply a full rootfs there :twisted: I you look inside deb-build.sh, the code handling %addbase and %addpkg is identical :twisted: :twisted:
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#18 Post by mavrothal »

jamesbond wrote: With abiword/gnumeric which depends on gtk3, you don't really have an option other than pulling all those gtk3 stuff :? I'd recommend making our own DEBs for these as they are not core to the system. (Xorg, however, is core, and we should keep parent distro's one).
indicative only wrote:# grep systemd repo-trusty-i386/pkgdb | wc -l
58
# grep libgtk-3 repo-trusty-i386/pkgdb | wc -l
540
# grep libgtk2 repo-trusty-i386/pkgdb | wc -l
1329
I'm very troubled with the fact that synaptics depends on gtk3, I hope there is a way to build it to depend on gtk2.
According to the synaptic home page it needs gtk+2.4 (or latter).
But distro compatibility and size will be a continuous battle that we can not win with 2-3 people behind puppy. Specially if we do not want to employ BK's elaborate "templates" system and mixing distro and non-distro binaries.
But I think for now lets try to get a fully blown system and see how does it do size, efficiency and functionality wise.
BTW would be handy to either utilize the puppy kernels (since the build scripts are there too) or provide a 32bit "fatdog-like" kernel (sorry too little time these days :( )
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#19 Post by 01micko »

Perhaps puppy typical gtk2+ programs (ie compiled light as possible) could go in a separate sfs (adrv?) and therefore not registering with dpkg. However that recreates an age old problem of stuffs in sfs not registering with package management. That could be addressed in a native package manager but then that defeats the purpose of this project.

The end user doesn't give a toss. Well, they toss the CD if it doesn't "just work". Likewise they don't want to know about terminals. A gtkdialog or gtkbuilder frontend for apt? Sounds scary/crazy eh?
Puppy Linux Blog - contact me for access

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#20 Post by jamesbond »

mavrothal wrote:Specially if we do not want to employ BK's elaborate "templates" system
I don't know what you mean by this. What is this "template" system?
and mixing distro and non-distro binaries.
I think this can't be avoided. Xdialog and gtkdialog already comes from ourselves. Synaptic will probably have to be our own too (thanks for pointing this out), and so will abiword/gnumeric be if we want to have them in reasonable size. But they must be done in the proper native package format so they get recorded. DEBs for Debian/Ubuntu, TGZ/TXZ for slackware, etc.
BTW would be handy to either utilize the puppy kernels (since the build scripts are there too) or provide a 32bit "fatdog-like" kernel
We don't need fatdog-like kernel, I did it just so I can quickly come up with a script that builds an ISO. Puppy's traditional initrd has a mixture of kernel modules in initrd and in basesfs. This is complicated, we need to copy some modules to initrd, do depmod, then copy the rest and firmware to basesfs, etc. This can still be done (although I don't provide the tool to do that), and the resulting puppy will still work.

So to simplify matter, I put *ZERO* modules in initrd. That's right, there is no modules in initrd. This makes the initrd, in a sense, "universal"; it can be used for any puppies. I use ZDRV exclusively to load kernel modules (kernel-modules.sfs). Basesfs (puppy.sfs) is free from kernel modules, and thus is universal too. If you want to update kernel, just update vmlinuz and kernel-modules - then you're done. No complicated unsquashfs/mksquashfs, no uncomplicated extracting initrd and rebuild.
For this to work, the kernel must be compiled with enough kernel modules to be able to find ZDRV and load it. It means loopback, aufs, squashfs, filesystem drivers, usb drivers (if we want to boot from usb) *must* be compiled to the kernel, not as a module. That's all there is to it. If puppy's kernel is currently compiled with that, then it should be straightforward to download puppy's kernel and build the ISO. Otherwise, either the kernel config needs to be modified, or we need to use standard puppy initrd build as above.
Perhaps puppy typical gtk2+ programs (ie compiled light as possible) could go in a separate sfs (adrv?) and therefore not registering with dpkg. However that recreates an age old problem of stuffs in sfs not registering with package management.
I personally think there isn't a problem with that. Apps in SFS, by its nature, ephemeral, they can be added or removed at anytime. So I don't see the need for them register with the native package management, and in general, it is not good for regular programs to depend on presence of such SFS.

That being said, if you really want to integrate them, for dpkg this is going to be a bit difficult (not impossible, but difficult). In slackware system, the installed packages are recorded in individual manifests in /var/log/packages. To give an appearance of an "installed" package, all you need to do is add one more package manifest in that directory and that package will be "installed." In dpkg, this is not that easy - packages are recorded in two places, one individual manifest like slackware in /var/lib/dpkg/list, one in big giant database called /var/lib/dpkg/status. It is the latter which gives us headache. But it is still possible - however, one needs to agree on having a "post-load" and "pre-remove" scripts to be run on SFS load/removal; and that script will be responsible to manipulate /var/lib/dpkg/status.
That could be addressed in a native package manager but then that defeats the purpose of this project.
A package manager which doesn't come from the parent has two problems.
1) It always suffers from "translation" problem. And as usual when translating something, some information or some context may be lost, which *may* cause issues later. That's the reason to stay with parent distro's manager.
2) Then there is this "current-ness" problem. How to know whether the cached, translated package database is not out of date compared to the parent distro's native package database?
Both of these are not intractable problems, and can be addressed (as the current PPM obviously shows), but they are still quite challenging nonetheless.
The end user doesn't give a toss. Well, they toss the CD if it doesn't "just work". Likewise they don't want to know about terminals. A gtkdialog or gtkbuilder frontend for apt? Sounds scary/crazy eh?
Not scary, but with the number of packages around ~44,000, you do need crazy optimisation to make gtkdialog fast :wink:
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

Post Reply