tazpkg view README.devel @ rev 847
Add 'mkdb' description to 'usage' and English docs. Refresh French translation (thanks Lucas Levrel)
| author | Aleksej Bobylev <al.bobylev@gmail.com> |
|---|---|
| date | Sat Oct 10 14:52:10 2015 +0300 (2015-10-10) |
| parents | |
| children | bbc6b0a453a7 |
line source
1 README file for TazPkg developers
2 =================================
5 Desktop integration
6 -------------------
8 mimeapps.list: this file deprecated and not installed
9 https://wiki.archlinux.org/index.php/Default_applications
10 (Also, defaults.list deprecated.)
12 MIME-type "x-scheme-handler/tazpkg" already listed in the tazpkg-url.desktop
15 Categories for .desktop files are listed here:
16 http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html
18 tazpanel-pkgs.desktop: sub-category PackageManager -> category Settings
21 TazPkg modules
22 --------------
24 About 4,000 lines of code is too big to effectively maintain it in single file.
26 Linux way [https://en.wikibooks.org/wiki/Linux_Guide/How_Linux_Works]:
27 > The Linux Way can be summarized as:
28 > * Use programs that do only one task, but do it well.
29 > * To accomplish complex tasks, use several programs linked together.
30 > * Store information in human-readable plain text files whenever it is
31 > possible.
32 > * There is no "one true way" to do anything.
33 > * Prefer commandline tools over graphical tools.
35 It decided to split single tazpkg code into few independent modules.
37 Goals: not to scroll thousand of lines to move forth and back to the internal
38 tazpkg functions and to the main tazpkg code; knowledge that single code
39 changing in the one place will not have side effect in the other place; reduce
40 the barrier to entry for new developers.
43 Place best fit tazpkg modules is /usr/libexec directory.
44 http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s07.html
46 > /usr/libexec includes internal binaries that are not intended to be executed
47 > directly by users or shell scripts. Applications may use a single subdirectory
48 > under /usr/libexec.
50 > Applications which use /usr/libexec in this way must not also use /usr/lib to
51 > store internal binaries, though they may use /usr/lib for the other purposes
52 > documented here.
54 So, directory for tazpkg modules is /usr/libexec/tazpkg/.
55 It is out of the PATH, so modules will not interfere with original Linux
56 commands and will not autocomplete in the terminal. Nothing changed with the
57 user experience: it is still single tazpkg.
60 To execute module we need to know full path to the module.
61 We can use simple names for modules such as "help", "convert", "list", etc.
64 Directory variables
65 -------------------
67 Many programs can be configured using variables such as prefix, docdir, etc.:
68 make prefix=/usr install
70 All variables are in lower case (only DESTDIR is in upper case). See more here:
71 https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
73 Makefile contains variables support with default values.
74 Default prefix=/usr, all other variables are defaults to values described
75 at the given link.
78 Code commenting
79 ---------------
81 Developer comments are very important to understand how program works.
82 But that comments are useless to the end user and they just increase the size
83 of the scripts without making any changes to the script business logic. It also
84 increase the size of the scripts that includes shared "libs" such as libtaz.sh.
86 We can strip all the comments from installed scripts, leaving that comments
87 for developers in the SliTaz Hg repositories.
89 We need only to leave "#!/bin/sh" line and one-two lines of comments described
90 what it is and where you can find the original scripts if you want to develop
91 them.
94 Tests
95 -----
97 Tests are the important part of the development process. TazPkg development is
98 not easy. We have no automated tests at the moment. Only we can do manual tests,
99 but we even have no check-list.
101 To test tazpkg effectively we need two sorts of the tests. One set of the tests
102 we can reproduce in the local file system (inside special prepared chroot
103 environment). For other tests we need special test-server that provide special
104 test cases (emulate package database changes), also provide both main and few
105 undigest repositories. We can set up special scripts and test repository on the
106 existing server (cook.slitaz.org).