Build: control file validation

The control file is strongly checked for validity. If anything is detected as invalid, an error is raised. It is considered very important because at the time it is used to install a package, no errors should ever occur while reading the control file (unless the package was damaged in some ways.)

Note that the contents of a certain number of fields are checked by the build process only. That means those fields can be wrong in a binary package and you can still load that binary package. This is useful for backward and Debian dpkg tool compatibility. For example, the Source field is forbidden by wpkg. It just cannot exist in a valid .deb file that was created by wpkg. The build catches that field existances and generates an error if found in the control file. The field is accepted by the control file reader however because some Debian packages make use of it1.

The following are all the things checked by the Build process. When creating a package using a control.info file, additional checks are performed as shown in the Build: control.info incompatibilities page. The control file loader checks are shown in the different entries specific to the Control File (click "up" below to find the list of all those entries.)

The Architecture field must be defined or the build fails immediately. Also it has to be a wpkg supported architecture other than any.

It is possible to define the owner and group of all the files in a package using these two fields. These fields must be properly formatted and only the Build process checks the format. If invalid, the build process breaks and returns.

The Package field must be defined or the build fails immediately. Also it cannot be set to a certain number of names such as "core" and "tmp".

  • Source

TheSource field is checked for existance. If present wpkg generates an error and stops.

  • 1. From what we can tell, the Source field is at times improperly used in binary packages as the Origin information.
Syndicate content