Package confusion in future puppies
March 28, 2009 —
BarryK
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|gedit-2.26.0.pet|+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...
Puppy5
Lobster,
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.
Comments
4.2 Final releasedUsername: Lobster
Thanks for 5 info Barry added here http://pupweb.org/wikka/PuppyKennel/ 4.2 Final released http://www.puppylinux.org/wiki/archives/old-wikka-wikki/categoryusercontributions/puppy-42-release-notes
4.2: not yet
Username: BarryK
"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).
'devx' too.
Username: BarryK
"Oh yeah, also 'sfs_modules-4' directory on ibiblio does not yet have 'devx_420.sfs'. http://distro.ibiblio.org/pub/linux/distributions/puppylinux/sfs_modules-4/ http://distro.ibiblio.org/pub/linux/distributions/puppylinux/pet_packages-4/
patch option
Username: big_bass
"http://www.murga-linux.com/puppy/viewtopic.php?t=39195&start=30 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 big_bass
Idiot-proof it
Username: PaulBx1
""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.
Tags: woof