Difference between revisions of "Bering-uClibc 4.x - Developer Guide - Policies and Guidelines"

From bering-uClibc
Jump to: navigation, search
(Created with simple initial content)
 
(Added policy of putting libraries into a separate Package and notes on Perl modules)
 
(5 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
! colspan="3" align="center" | [[Bering-uClibc 4.x - Developer Guide - Policies and Guidelines|Policies and Guidelines]]
 
! colspan="3" align="center" | [[Bering-uClibc 4.x - Developer Guide - Policies and Guidelines|Policies and Guidelines]]
 
|-
 
|-
| width="20%" align="left"  | [[Bering-uClibc 4.x - Developer Guide - Building an Image|Prev]]
+
| width="20%" align="left"  | [[Bering-uClibc 4.x - Developer Guide - Adding a Kernel Architecture Variant|Prev]]
 
! width="60%" align="center" | [[Bering-uClibc 4.x - Developer Guide]]
 
! width="60%" align="center" | [[Bering-uClibc 4.x - Developer Guide]]
| width="20%" align="right"  |  
+
| width="20%" align="right"  | [[Bering-uClibc 4.x - Developer Guide - Hints and Tips for using Git SCM|Next]]
 
|}
 
|}
 
----
 
----
  
  
The following general Policies and Guidelines should be adopted (if possible / practical) when developing for Bering-uClibc 4.x:
+
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 <tt>buildtool.cfg</tt>.
 
# Upload the upstream package source file to the LEAF source code management system and reference it from there within <tt>buildtool.cfg</tt>.
 
#* This provides a "local" copy in case the upstream distribution location changes or goes away.
 
#* 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.
+
#* 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.
 
# Store the upstream package source file in unmodified form.
 
#* Do not change the filename. Retain the original compression scheme (preferably <tt>.tar.gz</tt> but alternatively <tt>.tar.bz2</tt> if that is all that is provided).
 
#* Do not change the filename. Retain the original compression scheme (preferably <tt>.tar.gz</tt> but alternatively <tt>.tar.bz2</tt> if that is all that is provided).
Line 18: Line 18:
 
# 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>e100</tt> entry as an example.
 
#* Refer to the <tt>e100</tt> entry as an example.
 +
# 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.
 +
# 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).
  
  
 
----
 
----
 
{| summary="Navigation footer" width="100%"
 
{| summary="Navigation footer" width="100%"
| width="40%" align="left"  | [[Bering-uClibc 4.x - Developer Guide - Building an Image|Prev]]
+
| width="40%" align="left"  | [[Bering-uClibc 4.x - Developer Guide - Adding a Kernel Architecture Variant|Prev]]
 
| width="20%" align="center" | [[Bering-uClibc 4.x - Developer Guide|Up]]
 
| width="20%" align="center" | [[Bering-uClibc 4.x - Developer Guide|Up]]
| width="40%" align="right"  |
+
| width="40%" align="right"  | [[Bering-uClibc 4.x - Developer Guide - Hints and Tips for using Git SCM|Next]]
 
|}
 
|}
  
 
[[Category:Bering-uClibc 4.x]]
 
[[Category:Bering-uClibc 4.x]]
 
[[Category:Developer Guide]]
 
[[Category:Developer Guide]]

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:

  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 4.x distribution, which is required to comply with SourceForge terms and conditions. TODO: Add reference to those Ts&Cs.
  2. 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.
  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 e100 entry as an example.
  4. Do not place kernel Modules into Package .lrp files. Place Modules only in moddb.lrp and modules.tgz.
  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).



Prev Up Next