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

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

---

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

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 distribution, which is required to comply with SourceForge terms and conditions (see end of page).
2. Store the upstream package source file in unmodified form.
   • Do not change the filename. Retain the original compression scheme (preferably most compressed like .tar.bz2 or .tar.xz, but alternatively .tar.gz 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 e1000e buildtool setup as an example.
4. Do not place kernel Modules into Package .lrp files. Modules are provided with modules.sqfs. Hardware-related Modules are autodetected during boot, software-related modules needs to be referenced in /etc/modules or should be added to the Packages init script by calling mount_modules.
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).

Excerpt from Sourceforges Terms and Conditions:  "...In addition, the Code that you submit must also be made available in human-readable (i.e., “Source Code”) form. Whenever reasonably feasible, you agree that you will make Source Code available on or via SourceForge.net corresponding to Code that you post, submit, display or distribute. You must make Source Code available for all portions of Code that you have modified, enhanced or otherwise created derivative works from (with any such modification or derivative work being a “Change”)..." ( "Terms of Use")

---

Prev

Up

Next