Difference between revisions of "Bering-uClibc 4.x - Developer Guide - Policies and Guidelines"
From bering-uClibc
Davidmbrooke (Talk | contribs) (Added new guideline on where to locate files like .source based on Erich Titl email to leaf-devel 2011-09-14) |
Davidmbrooke (Talk | contribs) (Added policy of putting libraries into a separate Package and notes on Perl modules) |
||
Line 20: | Line 20: | ||
# Do not place kernel Modules into Package <tt>.lrp</tt> files. Place Modules only in <tt>moddb.lrp</tt> and <tt>modules.tgz</tt>. | # Do not place kernel Modules into Package <tt>.lrp</tt> files. Place Modules only in <tt>moddb.lrp</tt> and <tt>modules.tgz</tt>. | ||
# 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. | ||
+ | # If an application has shared library files which might be used by other applications, place these in a separate <code class="filename">''library''.lrp</code> Package rather than embedding them in <code class="filename">''application''.lrp</code> | ||
+ | #* See for example <code class="filename">libssl.lrp</code> (containing <code class="filename">/usr/lib/libssl.so</code>) and <code class="filename">openssl.lrp</code> (containing the <code class="filename">/usr/bin/openssl</code> executable). Users do not need to load <code class="filename">openssl.lrp</code> unless they specifically need the <code class="filename">openssl</code> command, since they can load the shared library separately. | ||
+ | # Consider the following when packaging Perl module (<code class="filename">.pm</code>) files: | ||
+ | #* If the Perl module is only likely to ever be used by a single application, package it within <code class="filename">''application''.lrp</code>. | ||
+ | #** 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 <code class="filename">''application''.lrp</code>. | ||
+ | #* 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. <code class="filename">cpan.lrp</code> to manage those. | ||
+ | #* If the Perl module is to be packaged by itself, name it as e.g. <code class="filename">perl-Config-General.lrp</code> (following the convention for other distributions like Red Hat Enterprise Linux). | ||
Latest revision as of 11:48, 5 November 2011
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:
- 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.
- 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.
- 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 |