Difference between revisions of "Bering-uClibc 6.x - Developer Guide - Policies and Guidelines"
From bering-uClibc
m |
|||
Line 17: | Line 17: | ||
#* Make changes by "patching" the unpacked files as part of the build process defined in <tt>buildtool.mk</tt>. | #* Make changes by "patching" the unpacked files as part of the build process defined in <tt>buildtool.mk</tt>. | ||
# When adding an extra kernel module to the <tt>kmodules</tt> source package, check whether there is any accompanying firmware (in <tt>/lib/firmware/</tt>). If there is, also specify that in the <tt>kmodules</tt> <tt>buildtool.cfg</tt>. | # When adding an extra kernel module to the <tt>kmodules</tt> source package, check whether there is any accompanying firmware (in <tt>/lib/firmware/</tt>). If there is, also specify that in the <tt>kmodules</tt> <tt>buildtool.cfg</tt>. | ||
− | #* Refer to the <tt> | + | #* Refer to the <tt>e1000e</tt> buildtool setup as an example. |
# Do not place kernel Modules into Package <tt>.lrp</tt> files. Modules are provided with <tt>modules.sqfs</tt>. Hardware-related Modules are autodetected during boot, software-related modules needs to be referenced in <tt>/etc/modules</tt> or should be added to the Packages <tt>init</tt> script by calling <code class=filename>mount_modules</code>. | # Do not place kernel Modules into Package <tt>.lrp</tt> files. Modules are provided with <tt>modules.sqfs</tt>. Hardware-related Modules are autodetected during boot, software-related modules needs to be referenced in <tt>/etc/modules</tt> or should be added to the Packages <tt>init</tt> script by calling <code class=filename>mount_modules</code>. | ||
# Within <code class=filename>buildtool.mk</code>, place "flag" files like <code class=filename>.source</code> directly alongside the source <code class=filename>.tar.gz</code> archive, not within the un-packed directory structure. | # Within <code class=filename>buildtool.mk</code>, place "flag" files like <code class=filename>.source</code> directly alongside the source <code class=filename>.tar.gz</code> archive, not within the un-packed directory structure. |
Revision as of 14:25, 31 October 2020
Policies and Guidelines | ||
---|---|---|
Prev | Bering-uClibc 6.x - Developer Guide | Next |
The following general Policies and Guidelines should be adopted (if possible / practical) when developing for Bering-uClibc 6.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 6.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 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
Prev | Up | Next |