Packages-puppy-common-official

I am taking some first steps to streamlining and simplifying the online PET package repositories.

Simplified PET search
In Woof, the file DISTRO_PET_REPOS has variable PACKAGELISTS_PET_ORDER, which specifies the order in which package database files are searched. The code in DISTRO_PET_REPOS is now simpler:

#110608 simplify search order...

PACKAGELISTS_PET_ORDER='Packages-puppy-common-official Packages-puppy-4-official'
#exs of DISTRO_COMPAT_VERSION: wary5, lucid, 4
[ "$DISTRO_COMPAT_VERSION" != "4" ] && [ -f Packages-puppy-${DISTRO_COMPAT_VERSION}-official ] && PACKAGELISTS_PET_ORDER="Packages-puppy-${DISTRO_COMPAT_VERSION}-official ${PACKAGELISTS_PET_ORDER}"


"common" PET repo
I am now maintaining the latest PETs that are likely to be required in all puppies, in Packages-puppy-common-official, which is a database of PETs found online here:
http://distro.ibiblio.org/quirky/pet_packages-common

This "common" repo is not just the architecture-independent PETs such as Pburn and Pmusic, but also PETs with compiled executables where those PETs are likely to be needed in all/most Puppy builds and possibly not available in another repo.

You will notice some big pkgs such as 'cups' and 'ghostscript' included. It is likely that the host (Ubuntu, Debian, etc) will provide such packages, but my alternative PETs are much smaller. Therefore, I placed them in -common- as an alternative choice when building your pup.

It should be noted that the database format does specify where the binary executable was compiled, for example ...|puppy|wary5|..., and the Woof build scripts check these fields looking for best match. Hence, the -common- repo can have, if required, multiple PETs of the same name, and the build script will choose the PET that was compiled in the most compatible host. For example, look at the 'dbus' PET.
Note though, these multiple PETs need only be created if required -- it may be that a PET compiled in say Puppy 4 will work happily in all later puppies -- and indeed, -common- does have many such PETs (compiled in Puppy 4).

Note that the PET search order is first for Packages-puppy-${DISTRO_COMPAT_VERSION}-official, if it exists. For example, Packages-puppy-lucid-official.

Online repo sub-directory
Note that database entries have a sub-directory field, but I encourage this to be left empty. This is because the Woof/Puppy scripts will automatically extract the "lucid" out of the above database file name, and expect the PET to be in subdirectory "pet_packages-lucid".

Note, unfortunately, the online sub-directory created for Lucid packages is 'pet-packages-lucid':
http://distro.ibiblio.org/puppylinux/
...therefore the sub-directory field is required in all Lucid database entries.

So, in future, if another sub-directory is required, say for Dpup "etch", then the packages db file would be Packages-puppy-etch-official and the online sub-directory should be 'pet_packages-etch'.
(also, in DISTRO_SPECS, would have variable DISTRO_COMPAT_VERSION='etch')

Packages-puppy-woof-official
This is now retired, gone. The sub-directory 'pet_packages-woof' is now gone from
http://distro.ibiblio.org/puppylinux/
I never really knew what that repo was for anyway.

Packages-puppy-5-official
This one is deprecated. The problem is that there is no single "5" version of Puppy, instead we have divergences such as "lucid" and "wary5".
Previously, Packages-puppy-5-official was in the PET search order for Ubuntu/Debian builds, but no more. So, if Lucid is using a PET in the -5- repo, move it to the -lucid- repo.

To continue to simplify things, it is likely that Packages-puppy-5-official and sub-directory pet_packages-5 will get deleted sometime in the future.


Posted on 8 Jun 2011, 8:58


Comments:

Posted on 8 Jun 2011, 14:14 by Terryphi
Osmo pet?
Excellent re-organisation of repo!

What about adding a pet for Osmo?


Posted on 8 Jun 2011, 14:47 by Iguleder
Excellent!
Great work, Barry! Thank you very much.

I'm working on another simplification for Woof at the moment - an experimental, new structure for distro-related files. Something like a directory named "distros", with "ubuntu", "slackware", "t2", etc' under it, while each of these has scripts like "extract_package" and "process_package_list" that have the same command-line arguments and same output.

This way, instead of having big, messy and hardcoded, not-so-flexible case statements, you just call "distros/$DISTRO_BINARY_COMPAT/script".


Posted on 8 Jun 2011, 15:21 by Iguleder
dir2pet Improvement
Barry, here's a little tweak for dir2pet which may reduce package size. advdef can easily shave about 5% with gzip -9 compression, without sacrificing performance or compatibility.

http://pastebin.ca/2076600