Bering-uClibc 5.x - Developer Guide - Policies and Guidelines
From bering-uClibc
Revision as of 13:14, 3 April 2016 by Kapeka (Talk | contribs) (mention to prefer better compression)
Policies and Guidelines | ||
---|---|---|
Prev | Bering-uClibc 5.x - Developer Guide | Next |
The following general Policies and Guidelines should be adopted (if possible / practical) when developing for Bering-uClibc 5.x:
- 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 5.x distribution, which is required to comply with SourceForge terms and conditions. TODO: Add reference to those Ts&Cs.
- 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 e100 entry as an example.
- Do not place kernel Modules into Package .lrp files. Place Modules only in moddb.lrp and modules.tgz.
- 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
Prev | Up | Next |