The ISO file has grown a bit, up from 83.3MB for 4.00beta1, to 83.9MB. This due to inclusion of cifs and xfs kernel modules and the libstdc++.so.5 library.
To find out what is new since 4.00beta1, read my blog posts below.
I did a test upgrade from a 3.01 'pup_save' and it seemed ok, except three icons on the desktop were wrong. I will look into that.
I have updated the "Package management" introduction page, at:
I looked through my puppylinux.com web pages yesterday and realised that there was nothing that introduces SFS files. These are a very powerful concept and probably under-utilized because people often don't know about it. So, I have added an introduction to SFS files in the "Package management" page.
Upgrading from Puppy2/3
Regarding running Puppy2 and Puppy3 packages in Puppy4, generally there should not be any problem. The same goes for Slackware12 packages. If you upgrade a Puppy2 or Puppy3 'pup_save' file, if Puppy detects any user-installed official PET packages then a precise list of missing dependencies (if any) will be displayed at bootup. Also a generic list is displayed to cover all other PETs and DotPups. The generic list of missing dependencies is categorized into GTK1, Tcl/tk etc. You can find this generic list in /etc/rc.d/rc.update.
Anyway, I was thinking, perhaps it would be convenient to bundle the missing (or at least potentially missing, as it depends on what package) packages into one "compatibility" package, one each for Puppy2 and Puppy3. Upgrading from Puppy2 requires less dependencies. That would make it simpler for those upgrading.
I made the point above about "potentially missing", as a great many Puppy2 and Puppy3 apps work as-is in Puppy4. Mostly this would be the GTK2 apps. But not all GTK2 apps -- Puppy3 Pidgin package for example needs the 'dbus' package, which is not in Puppy4 (but it is a Puppy4 PET package). Actually, a side note on 'dbus' -- I probably will put it into future puppies, from 4.1 onward, as it looks very useful -- also, application developers are increasingly expecting it to be in a distro as most of the other major distros have adopted 'dbus'.
The new PETget GUI allows choosing from Puppy4, Puppy3 or Puppy2 PET repositories at Ibiblio. The main reason that I decided to offer Puppy3 and Puppy2 is so that users can choose "legacy applications" that are no longer in the Puppy4 repository. I am thinking of GTK1, Tcl/Tk and Xlib applications. Many of these older packages are dead projects and will no longer be updated. There are still some active Tcl/Tk projects, and I can probably offer these latest in the Puppy4 repository -- or even offer them in the Puppy2 repository only. So, the rationale would be that Puppy4 users would think of the Puppy3 and Puppy2 repositories as where they can get legacy apps -- the PETget in Puppy4 only offers a subset of packages from these repositories that are likely to be of interest to Puppy4 users -- see /root/.packages/livepackage2.txt and livepackages3.txt.
I was wondering how the new PETget GUI could fit in with community package repositories. If a community repository could offer a "livepackage-community1.txt" file, that PETget can download, then it can be included in PETget.
This file would need to have the same format as a normal 'livepackages.txt' file, including any dependencies required to work in Puppy4. But, a community repository is likely to have PET packages organised into subdirectories, so the format of the 'livepackages.txt' file will have to be extended a little to include this information. Maybe like this:
"figurine-1.0.5" "figurine 1.0.5: Vector graphics editor" off "Graphic +netpbm,+fig2dev 624K" \
Add the path information:
"figurine-1.0.5" "figurine 1.0.5: Vector graphics editor" off "Graphic +netpbm,+fig2dev 624K /puppy4/graphic" \
I can make sure that PETget understands this extra field.
Note about that above example, each entry does not need a complete list of dependencies, just those likely to be missing from Puppy4. It doesn't do any harm if a dependency is listed that is actually already in Puppy, such as the 'netpbm' package. If a dependency, such as 'fig2dev' is not provided in the official Puppy4 repository, then PETget would expect it to be available in the community repository -- or probably PETget should look in the community repository first. PETget also understands if a specific version of a dependency is specified, such as 'fig2dev-1.2.3'.
Note that if a GTK1 package entry in the 'livepackages' file lists only '+gtk+12' as the dependency, that's okay, as the 'gtk+12' package will have further dependencies, such as 'glib10' and 'gdk_pixbuf10', and PETget will follow the chain and install all dependencies.
PETget could have a button: "Download latest file list" to grab the latest 'livepackages-community1.txt' file. Note, the file should be named starting with "livepackages" and end with ".txt" but the text between will be the identification of that particular community repository.
The above are some thoughts for further discussion.
Comments:Posted on 20 Apr 2008, 11:18 by GeoW
Another great release Barry.
Good job. Congratulations!
Posted on 20 Apr 2008, 14:27 by BarryK
You need to try Jesse's sunset background, which is in 4.00beta2, along with the Citrus GTK and JWM and Orange desktop icons -- it looks spectacular!
Posted on 20 Apr 2008, 14:38 by Lobster
Dingo beta 2
The best innovation seems to be the updates to the package manager :)
Have started a thread on the forum . . .
Posted on 20 Apr 2008, 15:27 by GeoW
Jesse's sunset is very nice, although it does have
a bit of an "end of the world" look.
Posted on 20 Apr 2008, 20:52 by ANOSage
Sorry Barry, this one's a complete lemon. Some comments in Forum. B1 was virtually flawless for me - best for a long while; b2 is unusable. Can't win 'em all! Keep up the good work.
No idea what is the "Name of the Puppy Linux mascot?" Used "Puppy".
My usual handle and P/W were rejected????
Posted on 21 Apr 2008, 8:03 by disciple
Suggestion for future enhancement to petget
Barry, I'm not sure in which situations (upgrading, or installing packages) petget still gives you a list of missing dependencies, telling you to record them so you can install them. But it would be handy if it also recorded them in some sort of log file :)
Posted on 21 Apr 2008, 13:04 by inged
Love the addition of the SFS info. It would be nice if a list of all SFS files exist.
Question: Could a SFS PETget-like be possible?
Posted on 23 Apr 2008, 8:50 by BarryK
Re: Community PET repositoriy
An extra thought. The path to the package should not be absolute, as PETget would already know the absolute path of the repository. Instead, just a relative path, like this (for example):
"figurine-1.0.5" "figurine 1.0.5: Vector graphics editor" off "Graphic +netpbm,+fig2dev 624K graphics/xlib" \