blob: b17d38839be50d8de4dec02770c2fe4df30b2ae0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
TODO:
* Support package relationship variables in control files.
* Make oh-strip obey a missing '-l' option.
* Check on file ownership and modes.
Future Plans:
* Package signing. [1]
* Calculate "Installed-Size" field values. [2]
* Compress documentation files. [3]
* Write an 'opkcreate' script like dh_make to create a new source package.
* Control field variables/macros (e.g. package version)
* Build platform-specific binary packages only when really necessary. [4]
Notes:
1: Requires opkg to be built with GnuPG and GPGME.
2: There is an inconsistency between the Debian Policy and opkg in the units
of this field. The Debian Policy defines this field in units of kibibytes:
The disk space is given as the integer value of the estimated installed
size in bytes, divided by 1024 and rounded up.
However, opkg apparently attempts to convert this value from bytes to
kibibytes in its determination of whether the package's data will fit on the
system:
pkg_size_kbs = (pkg->installed_size + 1023)/1024;
For now, we'll omit this field (as a result, opkg simply won't make sure
there is enough free space).
3: Follow the model of debhelper's dh_compress.
4: Currently, if a source package contains a file named 'config', all of its
binary packages are built for the target platform architecture. For
example, the 'opkg' source package installs platform configuration for the
'opkg' binary package; as a result, even 'libopkg.1' and 'libopkg.1-dbg'
(though not 'libopkg.1-dev', which is built for the "all" architecture) are
built for the target platform architecture. This problem is minor, since it
will only bloat package archives with functionally identical binary packages
and will not affect managed systems.
A solution to this issue is to separate build-time and run-time
configuration files into different lists in the source package format.
Build-time configuration files would be listed in a file named 'config' in
the package root (as they are now), and run-time configuration files would
be listed in 'config' files in binary package metadata directories (e.g.
'opkg.pkg/config' in the case of 'opkg'). Then, opkhelper will build each
binary package for the target platform only if there are build-time
configuration files for the source package or there are run-time
configuration files for the binary package.
|