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

From bering-uClibc
Jump to: navigation, search
(Added new guideline on where to locate files like .source based on Erich Titl email to leaf-devel 2011-09-14)
(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:

  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