woof-CE
woof-CE copied to clipboard
puppylinux-woof-CE
Define and document "official" releases a bit better?
(This is just a suggestion, with an example.)
I'd like us to define the following things more clearly, and document them better (on GitHub, the main website, Wiki, etc):
- define an "official" release
- our definition of "done":
- what is required before we consider the ISO itself "done"?
- what documentation is always required?
- which web pages must it be listed on?
- our "release cycle":
- how often do we release?
- how many "flavours" or versions do we release in one go?
- how do we follow up with updated/bugfixed versions?
- our definition of "done":
- how do we make all these things clear to new and existing users?
I propose we try to get a version we are all happy with, and make it easy to find on the site, wiki, etc.. I put together some ideas for discussion obviously.. The more controversial bits are that it:
- suggests multiple "flavours" of each official release to be released at the same time
- suggests certain packages always be made available at release time too
- suggests all official releases have a "Handbook" and "Developers Handbook"
- suggests all official releases have bluetooth working "out of the box"
- suggests touchscreen and Wacom tablet support "out of the box"
- suggests PS3 and Xbox360 pad support "out of the box" (
xboxdrvhandles both)
I do think we should support all these devices "out of the box" with an official release, as they are so damn popular and widely used.
Anyway....
So, here is my attempt:
Puppy Linux: Official Release Schedule
Table of Contents
-
Official release cycle
- The main release
- Other "flavours"
-
What makes a release "official"?
- Our "definition of done"
- Important additional packages
- "Community edition" releases
- "GuardDog edition" releases
Official release cycle
The main release
We do "official" Puppy Linux releases every two years or so.
Official releases are the communities "best efforts" combined - all the developers, designers, testers and users working together, with the aim of building "the best Puppy Linux ever".
Official releases differ to un-official releases in these ways:
- built by the "senior" developers
- built from a stable, long term support (LTS) base distro
- released with multiple "flavours" of the main version
- important additional packages available at release
- gets added to the official Puppy Linux website
- has proper documentation
- a Release notes page
- a README
- a Handbook
- a Developers Handbook
- download from the official Puppy servers
- supported by Puppy Linux developers and community at the Puppy Forum
Other "flavours"
Official releases are the "main" or "flagship" Puppy Linux releases, and come in various flavours, all released at the same time.
All "flavours" or versions of an official release are compatible with each other:
- use the same kernel version and build
- built from the same "base" distro (Debian, Slackware, Ubuntu, etc)
- built from the same version of base distro
- contain the same core (system) package versions
These "flavours" provide a choice of different desktop themes and environments:
- default (JWM) - JWM desktop, ROX file manager
- XFCE edition - Xfce4 desktop environment, Thunar file manager
- LDXE edition - LXDE desktop environment, PC-Manfm file manager
- Mate edition - Mate desktop environement, Gnome file manager
What makes a release "official"?
Our "definition of done"
These days, an official release usually ticks all these boxes:
- available to download in "hybrid" ISO format
- the entire ISO file is as small as possible (currently around 350mb)
- can be burned to CD
- can use
ddto copy ISO straight to a partition - can be booted from CD (no installation required)
- can be booted over a network (using PXE, no installation required)
- can be installed to USB, SD card, hard drive, and more
- available in both 32-bit and 64-bit versions
- based on the latest Puppy Linux codebase
- built with Woof-CE
- built from Ubuntu, Debian, Duvian, Slackware or T2
- built from the latest stable or LTS packages
- included and working "out of the box":
- support boot BIOS, UEFI,
- lots of firmware included for good hardware support
- support Linux, Windows and Mac filesystems (ext2/3/4, f2fs, sshfs, exfat, ntfs, fat32, hfs+)
- working ethernet and wifi for most devices
- working network shares (NFS, SAMBA, FTP)
- boots to desktop (on supported hardware, qemu and VirtualBox)
- working graphics, with OpenGL/DR, working sound
- easy setup on first boot: locale, timezone, keyboard, more
- works as a Virtual OS (using qemu or VirtualBox)
- working CUPS, with drivers for most printers
- working with popular drawing tablets (Wacom, etc)
- working with popular touchscreen laptops
- working bluetooth
- working with common USB and bluetooth joypads, controllers, etc
- working with common MIDI controllers and instruments (Akamai, Korg, etc)
- working with PS3 and Xbox360 controllers
- working media player supporting popular codecs etc
- a wide variety of desktop programs to meet most common needs
- the latest programs developed by the Puppy community
- access to lots more programs via package repositories
The above list is what you can expect inside an official release.
Important additional packages
Some packages rely on specific kernels. Some of these are important - in these cases, custom-made packages are made available with each official release:
- ATI graphics drivers
- Nvidia graphics drivers
- Steam (for games )
- VirtualBox (for running virtual machines)
- WINE (for Windows compatibility)
These packages will usually be available in PET or SFS format, and the download links for each listed in the official release notes.
"Community Edition" releases
About one year after an official release, there will usually be a "community edition" of that release.
Community Editions differ from official releases in these ways:
- updated system
- updated packages
- bugfixes and tweaks
- more programs included by default
- extra (user-contributed) package repositories installed by default
- more themes, icons and user contributed stuff
- therefore, a bit more "user friendly" than a regular Puppy
"GuardDog Edition" releases
About one year after an official release, there will be a "GuardDog edition" of that release:
- more secure, privacy-focused releases
- no need to install to anything - run from CD
- optionally save sessions to an encrypted "save file", or not at all!
- leave almost no trace of your activity between reboots
GuardDog Editions differ from official releases in these ways:
- asks before saving settings/session between reboots
- uses encrypted save files by default
- fewer packages installed by default
- additional security fixes and bug fixes
- Tor browser installed by default, with privacy/security addons
- lots of programs setup to use
torby default (usingwith-torscript) - some ad-blocking, anti-virus, privacy and VPN tools added
To release official flavors there needs to be a proper base. It currently doesn't exist.
And a collaborative effort dealing with the pkgs_specs, that doesn't exist either.
I guess projects like.,.... ...... ..................................... porteus.. have solved this issue.
This is what people is looking for https://ftp.nluug.nl/os/Linux/distr/porteus/i586/Porteus-v4.0/
I guess they use the native package manager and try to be a layer above the compat distro, not a whole system above the compat distro, DebianDog follows the same paradigm.
It will take a complete redesign to achieve that with ease.
To release official flavors there needs to be a proper base. It currently doesn't exist.
The "proper base" for the non-JWM flavours would be the main release, remastered!
It will take a complete redesign to achieve that with ease.
I don't agree at all.
We already create the required Xfce, Lxde (etc) packages to produce these flavours, but at the moment, we do an "official" release and only after that, we make the Xfce (etc) packages... then come the remasters, puples, etc....
A better way:
To achieve multiple flavours released at the same time as the main release, the main difference would simply be that we
- make the Xfce, LXDE (etc) packages before any final release, (during RC candidate phase)
- manually remaster the main "official" with the new desktop environments
- and only after that, we release all the ISOs together...
It's almost a matter of simply getting the PET and SFS makers of Xfce, LXDE, Mate (etc) to make them and polish them up during RC candidate release phase.
I guess they use the native package manager and try to be a layer above the compat distro, not a whole system above the compat distro, DebianDog follows the same paradigm.
Just so you know, with Pkg, we don't even need to rely on real people/users being package builders so much any more:
- Pkg can add 3rd party repos easily
- I mention cos some desktop environment packages will be in third party repos:
- Slackware might need
alienbob,slackonlyandrlworkmanrepos
- Pkg can combine multiple repo packages into a single SFS fairly reliably
- It can also merge a custom list of packages together
It would be pretty easy to create SFS packages of Xfce, LXDE (etc) this way ...
So you could do this:
- create a JWM + ROX puppy, get it to release candidate (RC) status
- boot the (still JWM only) RC candidate
- use
pkg sfs-combine xfce4 --with-depsto create an Xfce4 SFS, with all deps, from the compat distro (or third-party) repo packages - mount the SFS in the RC candidate
- manually tweak the experience (fix menu layout, icons, etc)
- rebuild a fixed Xfce SFS (that everyone can use, if they want)
- use
woofyorremasterpupto remaster the JWM only RC candidate, with the Xfce SFS included, booting to Xfce by default
By following these steps, you will have a XFCE flavoured Puppy, already at RC candidate status... alongside the "main" (JWM) one.
BTW, the only bit of all the above that is not scriptable is the remaster/woofy bit, cos we didn't separate the CLI and GUI
Possible idea (not important):
The "Xfce flavour" could even be built so that Xfce still lived inside a separate SFS on the ISO, and gets mounted automatically at boot - that way users would always get the same main puppy SFS on all ISOs/flavours, but with different additional SFS files, which could get mounted and ran automatically during the boot process.
(I have always thought we could have a special x.sfs or desktop.sfs containing desktop environment stuff, so users can easily switch between Xfce, Mate, etc.. A bit like the zdrive... )
I'd love to hear peoples thought on this...
Particularly the feasibility of this exact process:
Creating the required SFS addon
- get a "final" or "pretty much final" release candidate (RC) version ready
- boot the RC version
- use
pkg sfs-combine xfceto create an Xfce SFS (xfce and all deps) - mount the SFS, tweak and fix the Xfce menu, settings, etc
- put the tweaks and fixes into a new, final Xfce SFS
...later:
- finish the final "main" (JWM only) official release (but don't release it yet)
Creating the Xfce flavour ISO
Before releasing anything, building the various "flavours" could be done a number of ways. In each case, the new Xfce flavour should boot straight to Xfce desktop.
Using remasterpup:
- boot the final, official release
- mount the fixed Xfce SFS, restart X
- remaster, save the ISO as
puppy-***-xfce.iso
Using woofy:
- install Woofy in any recent Puppy
- run Woofy, choose the new official (JWM only) release as your base ISO
- in the "add packages" section, add the fixed Xfce SFS
- rebuild the iso as
puppy-***-xfce.iso
Using a desktop.sfs
This is my preferred option, but maybe not something that works (yet):
- boot any puppy
- unpack the new main release ISO
- add the fixed Xfce SFS to it, next to puppy_**.sfs
- rebuild the ISO as
puppy-***-xfce.iso
The steps above (using pkg to build the SFS inside the main release, then using remasterpup or woofy to create the new ISO "flavour") could be re-done for each desktop environment (or program like Kodi) that you wanted.
Re-using existing SFS files (originally built on other Puppy versions, not the new "official" one) would also suffice if required - as long as they worked as intended.
My preferred option
The last approach (using a desktop.sfs) is awesome because the main puppy rootfs SFS file is the same in all flavours, therefore we can :
For devs:
- update rootfs for all flavours at once
- update the desktop environment separately from the rootfs
- maintain and support various flavours really easily
For users:
- not tied to a particular desktop environment (DE)
- can load/unload DE at reboot, as needed
- can try or switch to a different DE, even if they downloaded a specific flavour:
- Examples:
- Tom: downloaded Xfce flavour, then tested out the LXDE SFS, now uses LXDE
- Dick: downloaded the LXDE flavour, now prefers JWM, just unloads his LXDE SFS
- Sally: downloaded the JWM release, then the Mate SFS, and sticks with Mate
This is all some good ideas! However, Puppy is not a bunch of people, being paid to work on Puppy, and have all the time in the world to do it. Puppy has never had and will probably never have, a set schedule, to do anything! About all Puppy versions are developed by one person. Only as long as that person wants to work on it. Only as much work as that one person wants to do on it.
You may get some of these ideas to work. If some way is found to get a team of people, to volunteer to work on one specific Puppy version, until complete. Each person working on a specific part of the Puppy version.
I understand what is being asked in this WOOFCE GIT thread.
There is ONE thing I take issue with in your initial "DONE" section. I DO NOT FEEL IT IS RIGHT to demand that a PUP be 'RESTRICTED' to 400MB. In 2005 this might be a realistic request (even then it is a bad one considering that a CD was 670MB). There are too many reason for me to list why that restriction be put in place is a bad restriction; everything from internet availability to the machines in public hands starting in 2005! We do NOT live in a pre-2005 world. There are hundreds of PUPs that were designed for the PCs of that era. WOOFCE continues to address developer build requirements in a world where PCs and networks, today, are capable of so much more.
NO DEVELOPER SHOULD BE RESTRICTED IN THEIR CONTRIBUTION.
I am NOT trying to encourage any discussion on this post. But I am hopeful we see merit in it. I just hope we understand why. So please dont "flame" me.
We "may" want to remove that particular restriction and encourage ALL PUPs that are developed to participate in the documentation outline.
imho
I DO NOT FEEL IT IS RIGHT to demand that a PUP be 'RESTRICTED' to 400MB. In 2005 this might be a realistic request (even then it is a bad one considering that a CD was 670MB)
I agree.
I don't intend ANY of it to be a hard "restriction" - who would enforce it? It's just a goal, an aim, a target..
Maybe change the pre-amble to be more clear - these are not hard rules, but aims, goals and conventions...?
I myself (if I were being selfish) would say any Puppy under 600mb or so... But I'm not even bothered about about it the exact size..
Maybe replace it with "smallest download size possible" or something? I don't mind.
..I think there's more controversial stuff in there than that ;)
EDIT: I updated it.. might be better?
About building "Desktop Environments" as SFS files
You may get some of these ideas to work. If some way is found to get a team of people, to volunteer to work on one specific Puppy version, until complete. Each person working on a specific part of the Puppy version.
Maybe the lead dev can just ask for SFS files to be made during RC phase, on the forum?
With Pkg doing 90% of the work, the devs can even release the "alpha quality" SFS themselves, for others to just fix up during RC phase...
I'd be happy to help make the SFSs using Pkg:
- boot the (JWM only) RC candiate (before it gets final release!)
- add any addiotional repos required:
pkg add-repo <repo-name> - run
pkg sfs-combine <some-desktop-environment> --with-deps - go make a cup of tea
- mount the SFS once its built, run
lddon the contents of the SFS ** - maybe download and install a few more packages to get it running
- change WM, restart X
- fix the menus, settings, etc,
- extract the DE SFS to tmp dir,
- copy in the fixes you did, and any extra packages you needed that Pkg didn't pick up
- update the ~/.packages/*.files list (if you manually added stuff to the SFS)
- update the pet.specs (if you added packages/dependencies to the SFS)
- rebuild DE SFS using
pkg dir2sfs <dirname> - post to dev as RC version of SFS (mention any extra packages you added)
** Pkg can do pkg ldd <pkgname>:
# pkg ldd freeciv
Searching for missing dependencies.. Please wait.
OK: freeciv_2.5.6-2_all has no missing dependencies.
OK: freeciv-client-gtk has no missing dependencies.
OK: freeciv-data has no missing dependencies.
OK: libfluidsynth1 has no missing dependencies.
OK: libmikmod3 has no missing dependencies.
OK: libsdl-mixer1.2 has no missing dependencies.
# or this
echo "$SOME_PKG_LIST" | pkg ldd -
Automating the process
See, Pkg combines the dir2pet, dir2sfs and even ldd functions with the power of repo package and dependency management ..
Pkg also makes it easy to add additional repos (PPA, ubuntu, debian, slackware.. all with the same cmd - pkg add-repo <stuff>)
So it's fairly easily to build your own PET and SFS files from packages that come from Puppy/PPA/Debian/Slackware (default or user-contrib/third-party) repos..
And with Pkg, it's easy to convert package types deb -> SFS, pet -> SFS, etc.
And just to labour the point, all of the above (except the bit about making a nice cup of tea) can easily be automated, by writing basic shells scripts that call Pkg.
Automating fixes for packages and even specific packages
We still can't "auto fix" the Xfce menus when we install Xfce PETs, debs etc (before making the SFS).. yet...
However, I already planned a (very basic) plugin system, which will enable pre/post-install fixes to live in
-
/usr/share/pkg/plugins/pre-install/<pkgname>/*.sh -
/usr/share/pkg/plugins/post-install/<pkgname>/*.sh - etc
See here: https://gitlab.com/sc0ttj/Pkg/issues/13
..then Pkg will even be able to automate the fixing of specific packages (on installation).. Cos pkgname could be gimp for all gimp packages, or gimp-<version> for specific ones..
These fixes, once installed, can then be copied into the new SFS file when it's made..
Also, I will make sure variables like PKGNAME, PKGVERSION, PKGARCH (etc) are available in the environment when each plugin script is called, along with all the vars from DISTRO_SPECS.
So, the logic for choosing which package or package version to apply fixes to should be easy to implement however devs see fit - put scripts in a specific dir, or check $PKGVERSION in the script, etc..
(And we might be able to move a lot of the zz_hacks stuff there too)
Plugins which runs for ALL packages, would simply go in:
-
/usr/share/pkg/plugins/pre-install/*.sh -
/usr/share/pkg/plugins/post-install/*.sh - etc (so, no package name in the path)
Here's the full list of "hooks" I planned (so far):
init/*.sh # run once before any opts/params processed
pre_cmd/*.sh # run before each given command
post_cmd/*.sh # run after each given command
pre_install/*.sh # run before pkg install
post_install/*.sh # run after pkg install
pre_uninstall/*.sh # run before pkg uninstall
post_uninstall/*.sh # run after pkg uninstall
pre_package/*.sh # run before converting dir to pkg
post_package/*.sh # run after converting dir to pkg
exit/*.sh # run once, just before exit
About the GuardDog addition, Puli has been going years, always supported and updated, very nicely done..
http://murga-linux.com/puppy/viewtopic.php?t=96964
Maybe get **gjuhasz ** to make a GuardDog, and release in line with Community Edition, every 2 years or so..
I will ask him about it.
- built with Woof-CE
Most Puppy-family distros in http://forum.puppylinux.com/viewforum.php?f=114 are built with a modified woof-CE that wasn't published and wasn't merged into https://github.com/puppylinux-woof-CE/woof-CE.
This is not what "open source" stands for.
@01micko Who maintains the list in https://puppylinux.com?
