PPkg is a project I've been working on that is a script based packager. It takes a "PUPPYPKG" file, reads the data in it, and compiles a puppy package from it.

PPkg has many improvements over new2dir and dir2pet, including:
- Making packages without answering any questions.
- Exporting in PET, SFS and/or RXZ formats.
- Automatic package splitting.
- Package signing implemented (but it can't be used with the PET format)
- Being able to easily share your packages and how you made them (most "pBuild" files are less then 1KB)
- Able to update a package by changing as little as one line (in some cases)
- With PPkg, you can compile an entire repository of packages for any architecture and for any puplet, in one command

The problem with PPkg is that there are only a few build scripts. If you have any experience with packaging, any help would be appreciated.Edited_time_total

ppkg --pet # make a PET package from the PUPPYPKG in the current folder
ppkg --pet --sfs --rxz # make a PET, SFS and RXZ package from the PUPPYPKG in the current folder
ppkg -P # compress the PUPPYPKG and any local sources (like patches) to a .pbuild.tar.gz file for easy sharing
ppkg --sfs -p packagename.pbuild.tar.gz # make a SFS from a pBuild
ppkg --pet -p *.pbuild.tar.gz # make a PET for all the pbuilds in the current folder
git clone git://github.com/noryb009/ppkg-scripts.git; ppkg --pet -P core/* # download the ppkg-scripts repository and make a pet package for each core package - this won't work until there are some packages in the repository

As you can see, ppkg is a tool that makes one (or two) commands save a LOT of time.

Quote:

you would need puppy build scripts for each Puppy series (2-5) right?

Not exactly. While there is a lot different between the series, the package management is mostly the same. It's possible to include some series/puplet specific code in a PUPPYPKG file, but most packages won't need it.

The problem with this is that if another user wants to create a PET of the same package for a different architecture or different puplet, or if they want to update the current PET, they have to do ALL the steps again.

PPkg helps the original packagers skip a few steps, and the other users skip all the steps. Packagers just need to fill out a form about a package, and edit a few lines. While this is about the same amount of work as compiling it normally, it makes compiling the package again very easy. They only have to run:

So once the template is provided a package can be compiled with the devx for 64 bit, Lucid, Slacko, Saluki, Racy, Wary ARM and MIPS (when available) etc?

Yes, once a packager creates a PUPPYPKG file for a program, it can be used for any puplet or architecture (pretty much).

Quote:

see src2pkg for package builds and pcompile for the GUI-

I haven't personally used src2pkg, but from what I have read, it is a good automatic packager for personal use. It can build a packages quickly, with hardly any setup or knowledge. However, I don't think it is powerful enough to be a distribution's package building system because of this line (line 117 in 15-make_package_pet):

Also attached is a pbuild.tar.gz file. Once you have installed ppkg, you can use the pbuild file to create a new pet package. All you have to do is download the attached pbuild (to a different folder then the PET to avoid overwriting it), then run the following command:

Code:

ppkg --pet -p ppkg-git-2012.02.13-1.pbuild.tar.gz

Please note: you need the devx, and if you are not in the same folder as the pbuild, you must specify a path to it.

src2pkg performs literally thousands of steps when configuring, compiling and packaging, so I don't think one line (line 117 in 15-make_package_pet) should be a show-stopper. It's simply a place-holder action which is waiting for a more complete routine to make it more useful. I decided to not waste time on improving that because the pet package format is so flawed and fluid.

As far as I can tell, pet packages and Puppy do not contain enough information to accurately determine the requirements of a package without resorting to very round-about methods. Anyone with any ideas about how to accomplish this are welcome to submit patches to src2pkg to fix this. We've been talking about this for a long time now, but I don't see where anyone has grasped the essential ideas necessary to make this work for puppy -it simply is inadequate to say: well, file belongs to 'base' or general-libs.sfs.

Still, if you have a list of what belongs to each unit, whether that is an sfs, some base installation and the contents of individual packages, then a system can be devised.

Finally, if you study the code there a bit, you'll see that it will use an already-prepared pet.specs file if one is available, instead of trying to generate one. So, the tedious way to overcome this is to prepare such a file for each package. You can always run the build once and then copy the resulting specs file into the CWD and edit it to complete it, then re-run the build to have it included. You could also use the src2pkg 'extensions' feature and write abit of code for an extension which pops a fancy gui and helps the user input the necessary data. Gettiung that data is the hard part -show me where there is enough info to automatically fill in thse fields and I'll work on it. But really, pets and all package management in puppy is woefully inadeqate for the job.

I would hope that you would do a bit of work to make src2pkg do a better job with this, rather than re-inventing what is a very good wheel. You have to understand that src2pkg has been under development and *heavy* use for nearly nine years now -there are thousands of pitfalls in config/compile/package processes which you will not find for years to come. And still, the pet format as it is not up to handling what you really want...

I have a system here where every single package is created using src2pkg, so I well know it is possible. But, the package creator has to be closely co-ordinated with the package format to achieve superior results. I wanted the capability to do dependency-resolution, so I designed my own package format and routines within src2pkg to go with that so that it is possible. I could certainly build such routines into src2pkg for other package formats, but my time is valuable and I would not waste it on what is essentially a no-go package format. src2pkg can only produce accurate dependency information for each package when all the packages or the package manager itself provide this info.

I decided to not waste time on improving that because the pet package format is so flawed and fluid.

I completely agree.

Quote:

I would hope that you would do a bit of work to make src2pkg do a better job with this, rather than re-inventing what is a very good wheel. You have to understand that src2pkg has been under development and *heavy* use for nearly nine years now -there are thousands of pitfalls in config/compile/package processes which you will not find for years to come.

Ppkg and src2pkg are similar, but work in different ways. Ppkg is meant to compile packages from pre-built scripts, allowing advanced packages to be created multiple times. Src2pkg is meant to compile packages, allowing packages to be created quickly. It also has a build script format, but from what I've seen, it does not contain much info about the package.

However, ppkg was not written for making PET packages. It was built for making PET2 packages - whatever they may be. Those packages would need some info that cannot be found in the source package, like dependency packages (different from dependency files), if a package cannot be installed with another package, and more, which is why PUPPYPKG files are used.

I haven't tried it, but it should be possible to use src2pkg to compile a package in a PUPPYPKG script, while letting Ppkg handle the package specs, signing, etc.

Quote:

And still, the pet format as it is not up to handling what you really want...

"does not contain much info about the package" All the info is *generated* by src2pkg at package-creation time. That means it is always current, uniformly-formatted and correct -and that you don't have to supply it all. Early on in the development-cycle of src2pkg, I could already see that I usually spent more time creating/editing the package description file than on anything else. So, one of the first automated-to-semi-automated thngs src2pkg did was generate them whenever possible, or produce a workable template at least.

In a couple of day I'm gonna post some example files for the tpkg-format (as produced by src2pkg) and output from some of the tipical commands that are available with the tpkg tools.

The src2pkg build scripts are designed to need as little manual modifications as possible. It's tedious to always have to be creating or editing them. They contain only essential information -transient or semipermanent options which can apply to any build are picked up from the conf file or the src2pkg command-line options. The minimum code for a build script is just *3* lines, and don't forget that sometimes you don't need one at all (a three-liner can't do any more than you can without any script at all). But, even a three-liner with a suffix like '.auto' gives you a visual clue that this package needs *no special treatment*, like package-dependent configure options, extra sources or the removal of files. You can even automatically upgrade a src2pkg script when you update the source version with just a command-line switch -I use thus heavily for building X & Co., where there are hundreds of source archives -just repace with the new tarballs and run: src2pkg -U -X name-of-tarball (the tarball name is usually handled with wildcards) -the script is updated (SOURCE_NAME and VERSION) automatically and then run...