Bering-uClibc 7.x - Developer Guide - Policies and Guidelines
From bering-uClibc
Revision as of 15:20, 31 October 2020 by Kapeka (Talk | contribs) (Created page with "{| summary="Navigation header" width="100%" ! colspan="3" align="center" | Policies and Guidelines |- | width...")
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:
- 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).
- 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.
- 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.
- 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
. - Within
buildtool.mk
, place "flag" files like.source
directly alongside the source.tar.gz
archive, not within the un-packed directory structure. - 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 inapplication.lrp
- See for example
libssl.lrp
(containing/usr/lib/libssl.so
) andopenssl.lrp
(containing the/usr/bin/openssl
executable). Users do not need to loadopenssl.lrp
unless they specifically need theopenssl
command, since they can load the shared library separately.
- See for example
- 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).
- If the Perl module is only likely to ever be used by a single application, package it within
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 |