MicroSUSE Packager's Guide

İçindekiler

1 Manually Building The MicroSUSE Distribution
2 Creating a MicroSUSE package
3 Packaging Rules
4 Guidelines for Packagers

Manually Building The MicroSUSE Distribution

Check out the current version from the Subversion repository at https://forgesvn1.novell.com/svn/microsuse/trunk/buildroot/.
Choose an architecture from the configs directory.
Copy the chosen buildroot config file to .config in the buildroot directory.
Run make oldconfig.
Run make.

After some time, if everything is OK, you should find a number of tarballs in the tarballs/<your architecture> directory. You will also find a cross-toolchain in build_<your architecture>/staging_dir. Note that you cannot move this toolchain to another directory. Instead, you have to change the relevant config option (BR2_STAGING_DIR) in the buildroot configuration, run make oldconfig again, and rebuild.

Creating a MicroSUSE package

First, you have to create a directory for your package in packages, for instance packages/foo.

Config System

To make it possible to enable your package, you have to create a Config.in file in that directory, containing something like this:

config BR2_PACKAGE_FOO
       bool "foo"
       default n
       help
         Foo is smaller than Bar.

If your package is specific to one or more architectures, add a dependency:

       depends on BR2_i386 || BR2_x86_64

This also works for dependencies on other MicroSUSE packages:

       depends on ncurses

The Makefile

The MicroSUSE build system is based on Make. Thus, you have to create a Makefile called <package>.mk (in our case, that would be foo.mk) in your package's directory that tells the build system how to compile and install your package. It has to have four phony targets:

foo: builds the package
foo-source: retrieves the source code from the Internet.
foo-clean: should do a make clean in the directory you build your package in.
foo-dirclean: should erase the directory you build your package in.

foo.mk could look like this:

#############################################################
#
# foo
#
#############################################################
FOO_TARGET_DIR=$(TARGET_PACKAGE_DIR)/acpid
FOO_DIR=$(BUILD_DIR)/foo-0.0.7
FOO_SOURCE=foo-0.0.7.tar.gz
FOO_SITE=http://www.foo.com/downloads/

$(DL_DIR)/$(FOO_SOURCE):
        $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)

$(FOO_DIR)/.unpacked: $(DL_DIR)/$(FOO_SOURCE)
        tar -C $(BUILD_DIR) -xvzf $(DL_DIR)/$(ACPID_SOURCE)
        toolchain/patch-kernel.sh $(FOO_DIR) package/foo/ foo\*.patch
        touch $(FOO_DIR)/.unpacked

$(FOO_DIR)/foo: $(FOO_DIR)/.unpacked
        $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)

$(FOO_TARGET_DIR)/usr/sbin/foo: $(FOO_DIR)/foo
        mkdir -p $(FOO_TARGET_DIR)/usr/sbin
        cp -a $(FOO_DIR)/foo $(FOO_TARGET_DIR)/usr/sbin/foo

foo: $(FOO_TARGET_DIR)/usr/sbin/foo

foo-source: $(DL_DIR)/$(FOO_SOURCE)

foo-clean:
        -make -C $(FOO_DIR) clean

foo-dirclean:
        rm -rf $(FOO_DIR)

#############################################################
#
# Toplevel Makefile options
#
#############################################################
ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
TARGETS+=foo
endif

Make Variables

Interesting Make variables you will have and/or want to use:

$(BUILD_DIR) is where you should create a subdirectory in which you compile your package.
$(TARGET_PACKAGE_DIR) is the package directory. Here, you should create a directory for your package and install the files required on the target system in it.
$(DL_DIR) is where you should download the source code of your package to, if it is not already there.
$(STAGING_DIR) is the location of the development system. Here, you should install all libraries, include files, documentation etc. that is necessary for development. Libraries go to $(STAGING_DIR)/lib (not $(STAGING_DIR)/usr/lib!), include files to $(STAGING_DIR)/include (not $(STAGING_DIR)/usr/include!).
$(SED), $(MAKE), $(STRIP), $(INSTALL), $(WGET), $(SVN), and $(TARGET_RANLIB) should be used instead of calling these tools directly.
$(TARGET_CC) and $(TARGET_CXX) are the compilers for the target system, $(HOSTCC) is the C compiler for the host system.
$(GNU_TARGET_NAME) is the target name as expected by ./configure.
$(GNU_HOST_NAME) is the host name as expected by ./configure.
$(TARGET_CFLAGS) are the compiler flags that should be used when compiling code for the target system.
$(TARGET_CROSS) is the prefix for the target cross-toolchain tools, should you require objdump or other weird things.
You should put $(TARGET_CONFIGURE_OPTS) before your call to ./configure when building autoconf-based packages. It sets CC, CXX, LD, and other environment variables to the correct values for cross-compilation. Mind that it does not set CFLAGS!

The easiest way to understand how these variables should be used is to look at some of the existing package Makefiles.

Packaging Rules

These rules are binding, no exceptions.

Use $(TARGET_CFLAGS).
All binaries in the target directory are stripped automatically. Do not strip files in $(STAGING_DIR), or install stripped files there!
For libraries:
- Install all libraries (both static and shared, as well as symlinks to these libraries) to $(STAGING_DIR)/lib.
- Install all include files to $(STAGING_DIR)/include.
- Install all shared libraries and modules required at runtime (and nothing else) to a directory under $(TARGET_PACKAGE_DIR)/<your package>/.
- Do not install any static libraries or header files in $(TARGET_PACKAGE_DIR)/<your package>/!
Documentation:
- Install documentation, man pages, info files etc. in $(STAGING_DIR)/man, $(STAGING_DIR)/info etc.
- Do not install documentation, man pages, info files etc. in $(TARGET_PACKAGE_DIR)/<your package>/!

Guidelines for Packagers

These guidelines should lead your thoughts in the right direction.

If you are in doubt about whether to enable a feature or not, consider these points:
- How costly is the feature if not used? How much disk space does it consume, how much RAM does it eat?
- Does it introduce dependencies? The answer better be no...
What to do with large packages:
- Is there a slimmer alternative, something that delivers more bang for the buck?
- Make them smaller.
- Split them.
- If the large size is caused by a specific feature, and the feature is important enough to keep it, make two versions of the package, one with the feature, and one without.
Try your very best to avoid dependencies. A package that requires OpenSSL and ncurses doubles the size of the base system!