slitaz-doc-wiki-data view pages/en/cookbook/devcorner.txt @ rev 7
Add pages/en folder.
| author | Christopher Rogers <slaxemulator@gmail.com> |
|---|---|
| date | Sat Feb 26 12:17:18 2011 +0000 (2011-02-26) |
| parents | |
| children |
line source
1 ====== Developer's Corner ======
3 SliTaz is an open source and community driven distribution. Everyone is welcome to join and contribute, from users, to hackers and developers, there is always something to do, i.e. proof-reading or writing documentation, sending bugs or patches to the [[http://www.slitaz.org/en/mailing-list.html|Mailing List]], gaining access to the wok and pushing some new packages or simply to help others on the [[http://www.slitaz.org/en/mailing-list.html|Mailing List]] or [[http://forum.slitaz.org/|forum]]. SliTaz has got [[http://hg.slitaz.org/|Mercurial repositories]] hosted on a SliTaz system. Developers can ask for a new repo if needed and contributors have write access to correct typos, scripts, etc.
5 SliTaz is a tiny community and listens to its users. There are several developers who are active on the [[http://forum.slitaz.org/|forum]] and the [[http://www.slitaz.org/en/mailing-list.html|Mailing List]].
7 For artists there is a dedicated [[http://community.slitaz.org/image|website]] -- simply create an account and post your graphics or pictures. The site is managed by the community. If you want to lend a hand to administer the site, please contact a contributor or e-mail the discussion list.
9 \\
11 ===== KISS & Comply to Standards =====
13 * First and foremost: keep it simple!
14 * Follow the most reliable standards in coding, documenting and all other areas of development.
15 * Carefully draft and write high quality documentation, including summarising complicated sections or processes, as well as detailed and informative tutorials.
16 * Provide a stable and robust system, and aim to keep the rootfs on the LiveCD light enough to run on machines with as little as 128 MB RAM.
17 * Use the range of tools available where possible; there is GTK+2, Dialog, SHell scripts and even PHP coding tools on the distribution and these are instantly available to everyone.
18 * The idea is to think small and not to duplicate.
20 \\
22 ===== Tank - Build Host & Home =====
24 Each contributor may have an account on the project server with secure access, disk space, a public directory and all development tools. Developers can compile packages and maintainers of the mirror can handle synchronization. [[http://tank.slitaz.org|Tank]] also hosts the website, web boot and mercurial repositories.
26 [[en:cookbook:buildhost|Instructions]] on using the build host are described in the Cookbook.
28 \\
30 ===== SliTaz Packages =====
32 The TazPkg packages in SliTaz are automatically created via TazWok and a receipt in the wok. The Cookbook [[en:cookbook:wok|describes]] the use of tools and the format of [[en:cookbook:receipt|receipts]]. These are required reading before creating SliTaz packages!
34 In terms of package selection, the idea is to offer a package by task or functionality, i.e. the lightest application in the field and not to provide another just on preference. Note that the current packages are not immutable, if you find an alternative that is lighter, with more features or more sexy for a few extra KB, you can suggest it on the [[http://www.slitaz.org/en/mailing-list.html|Mailing List]]. Particular attention is given to packages for the LiveCD, these should be stripped, removing unnecessary dependencies and compiler options. In general candidate packages for the core LiveCD are discussed on the [[http://www.slitaz.org/en/mailing-list.html|Mailing List]].
36 Before you begin to compile and create packages for SliTaz, be sure that the work doesn't already exist in the [[http://hg.slitaz.org/wok-undigest/|undigest wok]]. Don't forget that the members of the mailing list are there to help you and that the documentation of the [[en:cookbook:wok|wok and tools]] exists to help you get started.
38 \\
40 ===== Naming of Packages =====
42 In most cases the package name is the same as the source, except for Python, Perl, PHP, Ruby and Lua modules. For example, the package providing a //Kid// template system written in Python and XML is named: //python-kid//.
44 \\
46 ===== Mercurial Repositories =====
48 Mercurial, or Hg, repos can be browsed or cloned by anyone using the URL: [[http://hg.slitaz.org/|hg.slitaz.org]]. People with write access can directly use [[http://repos.slitaz.org/|repos.slitaz.org]] which requires authentication. Mercurial uses Python and is installable with:
50 <code>
51 # tazpkg get-install mercurial
52 </code>
54 \\
56 === ~/.hgrc ===
58 Before you push your first commit onto the server, be sure that you have a correct Hg configuration file with your name and email address, and remember to check that you are not root. Personal ~/.hgrc file example:
60 <file>
61 [ui]
62 username = FirstName LastName <you@example.org>
63 </file>
65 \\
67 === Clone, Modify, Commit, Push ===
69 <note important>You must be in the repository to be able to use 'hg' commands.</note>
71 * Clone a repo, example for wok:
73 $ hg clone http://repos.slitaz.org/wok
75 * Check all logs, or just the last log:
77 $ hg log
78 $ hg head
80 * Add or modify one or more files and commit:
82 $ hg add
83 $ hg status
84 $ hg commit -m "Log message..."
85 $ hg log
87 <note tip>You can use the command //rollback// to roll back to the last transaction.</note>
89 * Before pushing changes to the server, it is safe to pull once:
91 $ hg pull
92 $ hg push
94 Done! Your changes, code or corrections are now on the server.
96 \\
98 === Updating a Local Wok ===
100 To update your working directory with the changes that others have since committed to the server (//pull// the changes):
102 $ hg pull
103 $ hg update
105 \\
107 === Useful Commands ===
109 There are a number of commands that you may find useful:
110 * **hg help** -- Display the full list of commands.
111 * **hg rollback** -- Undo the last action performed (commit, pull, push).
112 * **hg log //<package>//** -- Display a package log.
113 * **hg head** -- Display the last log.
115 \\
117 ===== Implementation of iconv() =====
119 SliTaz uses iconv() provided by GNU glibc - any packages that offer libiconv must use the library contained in glibc-locale. There is therefore no longer a libiconv package (1.2 MB) in SliTaz.
121 \\
123 ===== Website Management and Books =====
125 The website and books (Handbook and Cookbook) are managed via a Mercurial repository, they can be cloned by:
127 $ hg clone http://hg.slitaz.org/website
129 Or if you have the proper permissions:
131 $ hg clone http://repos.slitaz.org/website
133 \\
135 ===== xHTML Coding Style =====
137 The website must have a consistent look-and-feel; this is also used in the wiki pages and local documentation. To achieve this:
139 * The pages and books are written in xHTML 1.0 Transitional.
141 * The colours for the body and the titles are placed directly on the page so the links are easy to follow.
142 * The title, a Level 1 heading, is used only once (at the top);
143 * Level 2 is the title of the document;
144 * Levels 3 and 4 are then used for the subtitles.
146 * If a list is used instead with smart anchors, it starts at the top just after the title of level 2.
148 * Paragraphs are always contained in <p> tags.
150 * For indentation, we use tabs. The reasons being semantics and to take up less space in terms of octets (bytes).
152 * To put code, like the name of a command inside a paragraph, <code> tags is the preferred method.
154 * Commands and terminal output are displayed with <pre> tags -- example:
156 $ command
158 * To view text that can be copied and pasted, such as scripts, bits of code, sample configuration files etc., use <pre> tags but with a CSS class named "script". Example:
160 <file>
161 <pre class="script">
162 code...
163 </pre>
164 </file>
166 * To emphasize words, use <em> tags.
168 * Internal links are relative.
170 * Remember to check the validity of the code with the online validator of the W3C.
172 \\
174 ===== The diff and patch Commands =====
176 The utilities //diff// and //patch// are command-line tools for creating and implementing a file containing differences between two files. This technique is often used for collaboration and the changes made to the original file can be clearly extracted. To create a diff file readable by humans in a simple text editor, you must supply the -u option:
178 $ diff -u file.orig file.new > file.diff
180 To apply a patch:
182 $ patch file.orig file.diff