Bering-uClibc 4.x - Developer Guide - Policies and Guidelines

Policies and Guidelines
Prev	Bering-uClibc 4.x - Developer Guide	Next

---

The following general Policies and Guidelines should be adopted (if possible / practical) when developing for Bering-uClibc 4.x:

1. Upload the upstream package source file to the LEAF source code management system and reference it from there within buildtool.cfg.
   • This provides a "local" copy in case the upstream distribution location changes or goes away.
   • This provides an input to the process which creates a downloadable snapshot of all of the source code used for a Bering-uClibc 4.x distribution, which is required to comply with SourceForge terms and conditions. TODO: Add reference to those Ts&Cs.
2. Store the upstream package source file in unmodified form.
   • Do not change the filename. Retain the original compression scheme (preferably .tar.gz but alternatively .tar.bz2 if that is all that is provided).
   • Make changes by "patching" the unpacked files as part of the build process defined in buildtool.mk.
3. When adding an extra kernel module to the kmodules source package, check whether there is any accompanying firmware (in /lib/firmware/). If there is, also specify that in the kmodules buildtool.cfg.
   • Refer to the e100 entry as an example.
4. Do not place kernel Modules into Package .lrp files. Place Modules only in moddb.lrp and modules.tgz.
5. Within buildtool.mk, place "flag" files like .source directly alongside the source .tar.gz archive, not within the un-packed directory structure.
6. If an application has shared library files which might be used by other applications, place these in a separate library.lrp Package rather than embedding them in application.lrp
   • See for example libssl.lrp (containing /usr/lib/libssl.so) and openssl.lrp (containing the /usr/bin/openssl executable). Users do not need to load openssl.lrp unless they specifically need the openssl command, since they can load the shared library separately.
7. Consider the following when packaging Perl module (.pm) files:
   • If the Perl module is only likely to ever be used by a single application, package it within application.lrp.
     • For example, if the module is written by the same developer as the application or is highly specific to the application.
   • If the Perl module is likely to be used by other applications, package it separately from application.lrp.
   • If the Perl module provides a Perl API for another standard component, consider packaging it with that component.
     • So for example, a Perl module for Berkeley DB access might be included in the same Package as the C library for Berkeley DB access (since the Perl module depends on the C library anyway).
   • If lots of small, sharable Perl modules need to be added consider creating e.g. cpan.lrp to manage those.
   • If the Perl module is to be packaged by itself, name it as e.g. perl-Config-General.lrp (following the convention for other distributions like Red Hat Enterprise Linux).

---

Prev

Up

Next