Package confusion in future puppies

Gedit recompiled
I had previously compiled Gedit on Intrepid-Puppy, as well as Gtksourceview. However, it does not work in Debian Lenny pup due to a missing symbol.

So, I need to recompile Gedit separately for Debian. Also, I want to use the compatible-distro packages as much as possible, so now using the Gtksourceview compat-distro pkg. Note, the reason why I cannot use the compat-distro Gedit is due to the extra dependencies that it has been compiled for.

I can create different Gedit packages and upload them to pet_packages-woof directory on ibiblio. The 'Packages-puppy-woof-official' package database file has entries for each, and the third-last and second-last fields identify what distro the package was compiled on -- the Puppy Package Manager reads this and is able to select the most appropriate.

For example, the entry for the Gedit compiled in Intrepid-Puppy looks like this:

gedit-2.26.0|gedit|2.26.0||Document|1404K|pet_packages-woof||+gtksourceview,+gconf,+dbus-glib|text editor|ubuntu|intrepid|woof|

This leads me to a question that Lobster asked me about Puppy after 4.2 and my reply...

My suggestion is that the base packages that were originally compiled in T2 for Puppy 4.0, form the base for the entire 4.x series. This especially includes glibc and the C/C++ compiler and most of the libraries.

There could be a 4.3, but it would continue with this code base. The 'pet_packages-4' on ibiblio will continue as the official PET directory for 4.x.

A Woof-built Puppy can be considered, but I think that it will need to be the start of the Puppy5 series. Also, you might have to choose one compatible-distro for Puppy5, to avoid creating lots of PETs and SFSs that work on one not on another.

...for example, I compiled Gedit in Intrepid-Puppy but it doesn't work in Lenny-Pup.

...this problem can be got round though, in a couple of ways. You could have separate PET repos for say the Ubuntu-Pup and the Debian-Pup. Or, a mixed repo like my pet_packages-woof ...I'll post about this on my blog.

In the first part of this post, I outlined how mixed packages can be in the same repo. As long as the database entry has those third-last and second-last fields that identify on what the package was compiled, the package manager is able to choose the right packages.

So, fingers crossed, you could embark on a Puppy5 that can be offered as multiple official builds, built as Arch-compatible, Debian-compatible, Ubuntu-compatible, or Slackware-compatible. When the package manager lists packages at a PET repo, it will (or rather should) only offer those that are compiled for that platform. In the Gedit example, running a Ubuntu-Pup, it won't matter that my pet_packages-woof directory on ibiblio has lots of Gedit pkgs, compiled for the other compat-distros, the package manager will only offer the right one.

The difficulty will arise where people download one individual PET package that they have found somewhere -- but then, that is a problem with any older Puppy also. Any individual PET package offered for download has to be clearly identified what build of Puppy it is designed to run on. Ditto for SFS files.

This is all still completely open. 4.2 is not yet out the door. Soon I'll bring out Woof-built alpha4 with hopefully a lot of things fixed, so testers can play with that and get closer making some decisions about the future.

Posted on 28 Mar 2009, 8:52


Posted on 28 Mar 2009, 11:59 by Lobster
4.2 Final released
Thanks for 5 info Barry
added here

4.2 Final released

Posted on 28 Mar 2009, 16:57 by BarryK
4.2: not yet
I won't announce it officially here on my blog until everything is uploaded. The 'puppy-unleashed-core-4.2.tar.gz' is not there yet, and the pet_packages-4 directory on ibiblio has not been updated with the latest 4.2 packages (last update was 14 March but some packages have changed since then).

Posted on 28 Mar 2009, 17:02 by BarryK
'devx' too.
Oh yeah, also 'sfs_modules-4' directory on ibiblio does not yet have 'devx_420.sfs'.

Posted on 28 Mar 2009, 22:11 by big_bass
patch option

I think we will need a new package option
called "Patch"

after installing an official lets say slackware package
and all its depends and if it still doesn't work
a patch package is used

is installed to finish
the job so when an update comes along it would be logical
to make a new patch and much easier to duplicate
the fix quickly since its just a difference patch

this way the patch is just applied to the original official package
an example libpoppler-patch-1-i486-1-woof.tgz
much better for reduced bandwidth too


Posted on 1 Apr 2009, 23:37 by PaulBx1
Idiot-proof it
"The difficulty will arise where people download one individual PET package that they have found somewhere -- but then, that is a problem with any older Puppy also. Any individual PET package offered for download has to be clearly identified what build of Puppy it is designed to run on. Ditto for SFS files."

*Sigh*. I was dreaming of a Puppy that could run packages from different repositories, but I guess I see that that would not work. Oh, well.

Anyway, couldn't you have the pets include a flag to show what repository the package is coming from, and simply refuse to install it if the base Puppy is different? Or at least to give a warning? Also give a warning if the flag is missing? I suppose that is what you were thinking of...

As to sfs files, maybe the different ones all have different checksums, and the bootmanager has a list of checksums that work with that version of Puppy, and it runs a checksum on the sfs file before loading it to make sure it is not from the wrong repository? I don't know if that would slow down boot significantly. Checksums seem to run pretty fast.

Posted on 1 Apr 2009, 23:59 by PaulBx1
Idiot-proof it
Oh, for .sfs files you could even just use the byte count to identify which one. That would take no time at all. I imagine sfs's built for the different distro-type Puppies are (usually) going to have different byte counts, right? Or could be made to have different counts I suppose.