Architectures in wpkg

Architecture Format

The format of the architecture specification is three words separated by dashes (-) as follow:

<operating system>-<vendor>-<processor>
    or
<operating system>-<processor>

Because most of the programmers want their packages used on any platform, the <vendor> specification is rarely used. However, if you are creating a controlled environment for a company, you may want to enforce such to make sure that 3^rd party packages cannot be mixed with that environment.

In our case we define two levels of vendors: a generic vendor (windows or ubuntu) and very specific vendors (winxp, win2k, or ubuntu_12_04, ubuntu_13_04.) Note that for MS-Windows the <operating system> is generally enough although someone may want to see a different vendor for cygwin and mingw. However, for Ubuntu, the <operating system> is set to linux which matches on Fedora, Mandrake, RedHat, etc.

IMPORTANT NOTES

Our architecture support is based on Architecture specification strings paragraph of the Debian Manual. However, contrary to what they do say about including the <vendor> information, we do offer the capability! As mentioned here, if you attempt to install packages from an invalid distribution, it is likely not going to work and thus we tend to think that is not what you'd want to do and thus we offer an easy way to avoid such mistakes.

The architecture specification is also defined in the configure script as defined by GNU where it is called the GNU System Type. Types are defined, tested, canonicalized by the config.sub shell script. Note also that for some reason the Debian Architecture and the GNU Triplet are inverted. Also, wpkg does not support the kernel entry, only the os and company (a.k.a. vendor). If you have a config.guess script, you can run it to determine the system you are currently running on.

As a vendor Debian specifies unknown as a possible entry. Also GNU often makes use of a simple common name such as pc.

Architecture API in libdebpackages

The API to access the architecture information of the libdebpackages is found in the libversion.c file. It is accessible from C programs as well as C++ programs. The header file is debian_packages.h and it defines a set of macros and functions. The macros can be used to compare the library you are dynamically linked against with the version you used to compile. If there is a mismatch you may decide to fail early.

if(strcmp(debian_packages_vendor(), DEBIAN_PACKAGES_VENDOR) != 0)
{
    fprintf(stderr, "The Vendor of this library does not match the expected vendor of our tool.\n");
    exit(1);
}

Note that the debian_packages_machine() function returns what the libdebpackages thinks the machine it is running on is. This is pretty much always different from what the canonicalized processor name is defined as.

wpkg commands

wpkg has commands that print out the architecture information in your console:

• --architecture
  Prints: <operating system>-<processor>
• --os
  Prints: <operating system>
• --processor
  Prints: <processor>
• --triplet
  Prints: <operating system>-<vendor>-<processor>
• --vendor
  Prints: <vendor>

The triplet is rarely used with packager environment unless you want to enforce the vendor information. This is why we have a --triplet command and an --architecture command. The --architecture output is what is expected to be used in most cases.

Functions Available in Control Files

Control files can run some expressions with the use of the $(...) syntax. The libdebpackages library adds the following functions to allow users to gather information about the architecture the wpkg project was compiled with:

• architecture()
  Returns: <operating system>-<processor>
• os()
  Returns: <operating system>
• processor()
  Returns: <processor>
• triplet()
  Returns: <operating system>-<vendor>-<processor>
• vendor()
  Returns: <vendor>

For example, you may want to have a clear separate vendor field in your control files:

Vendor: $(vendor())

Supported Architectures

At this point wpkg is limited in the number of architectures it supports. It is hard coded internally so as other developers want to make use of wpkg on different platforms, additional architectures will be added to wpkg.

The architecture of packages is checked in the wpkg_control.cpp file. If a package being loaded has an unsupported architecture at build or installation time, then wpkg rejects the command with an error.

The following table are the supported architectures and their abbreviations:

Other architectures may be added at a later time. At this point, we only support Linux and Windows in 32 and 64 bits architectures. However, wpkg is programmed to compile with cmake under pretty much any Unix platform. On the other hand, it may be easier to just reuse dpkg directly (which is what MacPorts did, for example.)

Accepted Operating Systems

Since version 0.9.0 wpkg accepts all the operating systems that Debian accepts. The following table shows the complete list. This means anyone who wants to create a Debian package for such an operating system can do so with wpkg.

Accepted Processors

Since version 0.9.0 wpkg accepts all the processors that Debian accepts. The following table shows the complete list. This means anyone who wants to create a Debian package for such a processor can do so with wpkg.

Installation Target Architecture

When creating a target you use the --create-admindir command line option with a control file including an Architecture field. The control file is expected to also include the name of a maintainer with his email address. Any other field is ignored by the system.

wpkg --admindir /var/lib/wpkg --create-admindir target

This architecture field can later be read using the --print-architecture command line option.

Architecture Patterns

wpkg supports architecture patterns when checking a package against an installation target. The patterns are built using the special keyword "any". To accept absolutely any architecture, use "any-any" (abbreviated "any"). To accept a specific operating system, but any processor use "<operating system>-any" (i.e. "linux-any"). To use a specific processor but any operating system use "any-<processor>" (i.e. "any-amd64"). By default the vendor is viewed as "any" when unspecified. You may explicitly define the vendor: "linux-any-amd64" accepts packages from any vendor that run on a linux 64 bit platforms.

IMPORTANT NOTE

"amd64" by itself represents "linux-amd64" and not "any-amd64". Similarly, "win32" by itself really means "win32-i386". However, "linux" by itself is taken as "linux-any". To avoid any problems, we suggest that you always specify both, the operating system and the processor.

Architecture Constraints

When installating a target system with the --create-admindir command line option, you must specify a full architecture name (<operating system>-<processor> or <operating system>-<vendor>-<processor>). If you give an abbreviated architecture for which we can infer a full architecture (as per the abbreviations defined in the table above,) then specifying such is allowed. Anything else is forbidden. Note that for a target system "all" and "source" are never allowed.

When installing a package on a target system, the package must have the exact same architecture or it gets refused. Packages marked as "all" (usually documentation) or "source" (source code of a package) can be installed on any target.

It is possible to allow a package on a target with an incompatible architecture using the --force-architecture command line option. It is strongly advised that you do such only while testing different settings on a development system and never on a production system.

The <vendor> information is optional. When present in the information installed with --create-admindir, all the packages installed on that target must match that <vendor> specification. Note that you cannot use something like linux-any-i386 because patterns are not allowed here. The --force-vendor option can be used to allow the installation of a package with an incompatible vendor information.

• 1. You could also make use of the versioncmp() function to compare two versions against each other.