FAQ

Frequently Asked Questions

Are you a fork of the wpkg.org software?

No. wpkg.org is quite different from this wpkg tool. From what we can see, wpkg.org software is exclusively for MS-Windows, ours works on many platforms, including many Unices.

What wpkg.org is strong for is remote distribution, for companies that develop software and want to distribute it from their company server.

Our wpkg is strong for the management of a large number of projects (packages). Although we do want to add additional support for installations from remote locations, it is not our primary goal because our software is mainly used on embedded systems which do not require such at the moment.

Reading more about both solutions will give you additional information and give you a better way to choose between one or the other solution. Of course, we prefer ours...

Do you have a Graphical User Interface (GUI)?

Yes. Package Explorer is the tool that let you manage an installation system from within a window.

We have a version that works with 0.8.x and a version that works with 0.9.x.

I am looking into a way to handle packages from my software, how do I do that?

Fortunately, all the code handling the wpkg compatible packages is part of the libdebpackages library. The wpkg command line tool is really only using that library API to do all the work it can do as specified on this website. Similarly, Package Explorer uses that same API. So there you have two good and rather extensive examples of how to use the library.

When creating a package from a setup.exe, wpkg uses over 2Gb of memory! Is there something I can do?

By default, wpkg uses the best possible compressor. That means it compresses with one, then another and keep the smallest, then another and keep the smallest, etc. until all compressors were checked out.

If you are creating a package with a setup.exe, however, that file is already well compressed and trying to compress it again generally results in a very small gain in terms of size. One solution is to use the --compressor command line option with 'none'. That tells wpkg to not bother with compression and thus a much smaller memory foot print at the time you generate the package.

If you are not dealing with a file that is already compressed, then you may still use the --compressor with a specific compressor name. For example,

wpkg --compressor bz2 ...

because that way you prevent wpkg from trying all the compressors. That will make it a lot faster and avoid the large memory footprint.

What build systems work with wpkg?

Since version 0.9.0, wpkg includes all you need to actually create a build system from all your wpkg aware projects.

This environment allows you to create source packages and then build a distribution from all those packages.

Details about how to use wpkg as a build system are found in the Using wpkg as a build system page.

How would I go about creating two packages of the same library that run with VC 2010 and VC 2012?

It generally depends on your situation, but this can be achieved in two different ways. Since version 0.9.0 the architecture field supports a vendor specification. That vendor specification could be set to vc2010 to force all the packages to be installed to have been compiled with VC 2010.

If you cannot yet use version 0.9.0 and still need such a check, you may fallback on the --verify-fields option and a field named X-API or something of the sort. Note that can also be used with version 0.9.0 and over.

wpkg --verify-fields 'get_field("X-API") = "vc2010"' --install ...

This checks whether the field is set to vc2010 before the installation proceeds. If not, prevent the installation altogether.

I write C++ libraries, how would I handle changes to the ABI?

Although I like writing code in C++, one of the huge drawback of that language is its lack of compatibility between versions.

The main problem you encounter are virtual functions. If you re-order, add, or remove functions in a C++ class, then the virtual table changes. This also applies to variable members which change the size of the object. That makes different versions of the library incompatible between each others and it is often very hard to know that you've made such a change until someone else tells you their software stopped working.

In any event, the way to handle this problem, assuming you know you are making the change, is to use the version number and properly depend on your C++ libraries. The version is composed of a major number, minor or release number, and a patch number. The release number should be increased each time the ABI changes (i.e. a virtual table was modified.) Then the Depends field can be defined as:

Depends: library (>= 1.2.0), library (< 1.3)

This means the library with a compatible ABI is version 1.2.x. A smaller version 1.1.x is not compatible because the ABI differs. A larger version 1.3.x is not compatible again because the ABI differs. So you have to upgrade that package if you want to upgrade the library.

In some situations, some businesses make use of dependencies with exact version references. This is a good idea if you are creating an embedded software so that way only the exact versions, as specified at engineering time, get installed.

Depends: library (= 1.2.0)

How to determine whether the ABI of your library changed is beyond this documentation and it looks like most programmers do not think there is a need for a tool to determine such... Too bad because such a tool would really be handy for this purpose.