PPkg - script-based packager

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#16 Post by noryb009 »

"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.
While the basic info needed for the PET format is generated (name, version, description), it doesn't (and can't) get some info, like it's dependency packages (you can automate some, but can't catch everything), if a package should be split (not into a DEV package, but one source into 2 different packages like "linux" and "linux-source"), and what architectures it can be built for.

The ppkg build scripts are designed to need manual modifications, but automate generic parts. It's tedious to always have to be generating them then merging the old version's options. They contain only essential information and info that removes the need for command-line options -transient or semipermanent options which can apply to any build are picked up from the conf file. The minimum code for a build script is just *5* lines, 1 of which is "}", and don't forget that sometimes you just need to fill in the source file, name, and version. You can even automatically download and compile a new version when you update one line. Where there are hundreds of source archives - just run `ppkg --pet -p *.pbuild.tar.gz` to compile everything.
See what I did there? :P

Ppkg doesn't generate anything, it gives you a template to start off with. If Ppkg was made for the PET format, packages would only have to fill in 8 fields - name, version, revision, description, category, arch, deps, and sources. In comparison, src2pkg needs 1.5 (sources and partially description), ignores 2 (arch and deps), and generates the rest (which only takes a minute to fill in to a PUPPYPKG file).
A PUPPYPKG file is easy to write, but allows packagers the power needed for "advanced" packages which need lots of patches, make flags, custom configuration files, symlinks, and moving files between split packages.
A big part of Ppkg is pBuild files - tarballs that can be compiled, which include any local sources that cannot be downloaded from the internet, without needing your own server to host the files.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#17 Post by amigo »

"get some info, like it's dependency packages" You can only get this info if it available. I mean only by having a complete list of every file and link contained in or created by a package -for every package. This is where the package format and the package-management system comes into play. If the installation of the packafe doesn't preserve or generate such a list, then dependency reolution is impossible. I'll give you an example.

Slackware packages do not contain a file/link list. But, on installation a file list is created and appended to an info file generated during installation. The links can be derived from the doinst.sh script by expensive parsing. Re-moving a Slackware package actually does a form of dependency resolving, in that before a file is removed from the system,all the files lists (the ones generated at installation time) are checked to see if the file also belongs to some other package. If so, then it is not removed. This is the only way to sanel remove or upgrade a package.

The reason that no dependency-resolution is possible with Slackware - vis-a-vis installing other packages which are needed by the one you want to install, is that when slackware packages are built, no information about these other packages is included. In order to generate that info you need the file-lists from all packages. It is a chicken-egg situation, but works fine if you build the whole system that way. And the file/link list for each package is the only thing needed to accomplish it. for instance, when you have the content created for a new package, you run or 'ldd' or some better program on each ELF object in the content. That will show you the *library* dependencies the object has. For each needed library, you look it up in the database to see which package it belongs to. The resulting package name is what your new package depends on. Simple -seemingly. More elaborate and complete dependency information must be found using more exhaustive methods -and sometimes info has to be supplied manually. for instance, there is hardly a way to determine that the 'man' program really needs 'groff' in order to function. Still, src2pkg has been able to overcome some of these snafus and you can always add any special depends info -without giving up on the automatically-generated info -which is dynamic and can *only* be generated at package-creation time. It does not work to use some arbitrary hand-created list of dependencies for packages, because as soon as you change compile-time options or the mix of packages installed at package-creation time, then the dependencies are subject to change.

src2pkg *does* automatically determine whether a package should be split into sub-packages or not -but only if you tell it to use that option. Not everyone wants split packages -Slackware doesn't use them at all, so it has to be a controllable option and not an arbitrary action. Plus, there are times when even you will not want to split a package. Take for instance the package 'man-pages'. That's a huge set of man-pages for system functions, etc. It is comprised of only man-pages. So, you surely wouldn't want to split the docs package there -nothing would be left in the original package. src2pkg even figures out which man-pages should be part of the 'devel' package, which should be part of the 'nls' package and which are english-only man-pages for a normal user -not a developer.

Just for the record, about how many packages and sfs's have you created in total? Have you even partially implemented your new package format with tools that create the packages and tools which install/upgrade/remove them? Have you studied any of the other package formats and their features?

I have created *way* over 100,000 packages using src2pkg -using other peoples package formats -including *.pets. I haven't gotten there yet with my new package format, but it is certainly over 5,000 -my system currently has about 1500 packages and they have been mass-rebuilt many times already.

noryb009
Posts: 634
Joined: Sat 20 Mar 2010, 22:28

#18 Post by noryb009 »

If the installation of the packafe doesn't preserve or generate such a list, then dependency reolution is impossible.
It isn't impossible if the user inputs dependencies - which is more accurate and flexable.
Slackware packages do not contain a file/link list. But, on installation a file list is created
Same as puppy. However, this means that you have to have every dependency installed before you build a package.
It does not work to use some arbitrary hand-created list of dependencies for packages, because as soon as you change compile-time options or the mix of packages installed at package-creation time, then the dependencies are subject to change.
This was one of the only things left to do in Ppkg - package-time library dependencies. I haven't done it until now because it wouldn't be used with the current package formats (and it's harder to bugtest then just signing). I'm planning to add needed libraries to the dependency array, and provided libraries to the non-existent provided array.
Just for the record, about how many packages and sfs's have you created in total? Have you even partially implemented your new package format with tools that create the packages and tools which install/upgrade/remove them? Have you studied any of the other package formats and their features?
I've not created too many PET packages - only about 30 - not using Ppkg. I hated the experience. Compared to any other distribution I've tried, which includes Mint, Arch, and Gentoo, it was like the stone age of packaging. I built Ppkg by taking the strong points of these package systems, and more. Ppkg can use any building system (make, cmake, ...), from any source (a tarball, git, svn, etc.), for any puppy package format (PET, SFS, and RXZ). Obviously, Ppkg is new, so it hasn't built thousands of packages, but the few scripts I have written so far in my spare time has been very easy.

Post Reply