summaryrefslogtreecommitdiffstats
path: root/dev
diff options
context:
space:
mode:
Diffstat (limited to 'dev')
-rw-r--r--dev/archive/signing.mdwn16
-rw-r--r--dev/pkg/needed.mdwn14
-rw-r--r--dev/ports/hardware.mdwn18
-rw-r--r--dev/releases/1/packages.mdwn11
-rw-r--r--dev/shlibdeps.mdwn78
5 files changed, 129 insertions, 8 deletions
diff --git a/dev/archive/signing.mdwn b/dev/archive/signing.mdwn
index dbd094e..83d98df 100644
--- a/dev/archive/signing.mdwn
+++ b/dev/archive/signing.mdwn
@@ -14,10 +14,9 @@ Implementation
ProteanOS Archive Manager
-------------------------
-[[pro-archman|dev/pro-archman]] will gain two new options: one to enable archive
-signing and one to specify a signing key. If archive signing is enabled,
-pro-archman will run `gpg` to sign, with the specified key, `Packages` feed
-index files when generated.
+[[pro-archman|dev/pro-archman]] will gain a new option: an archive signing key.
+If a key is provided, pro-archman will run `gpg` to sign, with the specified
+key, `Packages` feed index files when generated.
A `gpg` executable will be an optional dependency, found by the `configure`
script at build time.
@@ -52,6 +51,15 @@ prokit. prokit should find and use only archive signing keys (by a user ID
specified in the profile) that are signed by a non-revoked previous key (or a
signed chain of keys with the user ID).
+A user already has to import a key into their own keyring to verify their prokit
+download. Maybe it's better to just instruct users to also download the archive
+signing key(s) into their keyrings. This takes advantage of existing PKI, and
+leaves users to make sure their keyring is kept updated with signatures,
+revocations, changed expiration dates, and transitions. It also avoids having
+released prokit versions "expire" due to included keys expiring.
+
+Suggestions welcome.
+
Opkg
----
diff --git a/dev/pkg/needed.mdwn b/dev/pkg/needed.mdwn
index a1fcd20..d96b166 100644
--- a/dev/pkg/needed.mdwn
+++ b/dev/pkg/needed.mdwn
@@ -23,6 +23,20 @@ the [work by Neil Williams for Debian][debian-perl-cross].
[perl-cross]: https://lists.debian.org/debian-embedded/2012/06/msg00011.html
[debian-perl-cross]: http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/239-Long-term-maintenance-of-perl-cross-build-support-in-Debian.html
+Ruby 2.5 (`ruby`)
+-------------------
+
+<https://www.ruby-lang.org/>
+
+Ruby is a language interpreter with an easy to learn syntax, used for many different projects and is one of the most popular languages.
+
+Python 3.7 (`python`)
+---------------------
+
+<https://www.python.org/>
+
+Python is an easy to learn language and like Ruby is used in many different projects like: Game Development, Web Servers and even Console Programs.
+
GNU Autoconf (`autoconf`)
-------------------------
diff --git a/dev/ports/hardware.mdwn b/dev/ports/hardware.mdwn
index 4b8134a..453ba99 100644
--- a/dev/ports/hardware.mdwn
+++ b/dev/ports/hardware.mdwn
@@ -166,6 +166,24 @@ See also:
* [Information on AMD Family 10h][amd-fam10h]
+MIPS
+====
+
+64-Bit MIPS (little-endian) Microarchitecture
+---------------------------------------------
+
+ Status: Potential
+ String: mips64el
+ Byte order: little-endian
+ GCC CPU name: mips64el
+
+32-Bit MIPS (little-endian) Microarchitecture
+---------------------------------------------
+
+ Status: Potential
+ String: mipsel
+ Byte order: little-endian
+ GCC CPU name: mipsel
[intel-80486]: https://en.wikipedia.org/wiki/Intel_80486
[intel-p5]: https://en.wikipedia.org/wiki/P5_%28microarchitecture%29
diff --git a/dev/releases/1/packages.mdwn b/dev/releases/1/packages.mdwn
index bb7df49..12bd1dc 100644
--- a/dev/releases/1/packages.mdwn
+++ b/dev/releases/1/packages.mdwn
@@ -44,10 +44,12 @@ packages:
ich9deblob 20150518fix~git20150628.0e3520f-1
iptables 1.4.21-2
libarchive 3.1.2-1
+ libassuan 2.5.1-1
libexif 0.6.21-1
libffi 3.1-1
- libgpg-error 1.12-1
+ libgpg-error 1.32-2
libjpeg-8 8d-1
+ libksba 1.3.5-1
libnl-3 3.2.25-1
libogg 1.3.2-1
libpng12 1.2.51-2
@@ -64,6 +66,7 @@ packages:
mpfr 3.1.1-1
mplus-fonts 058-2
ncurses 5.9~20140301-2
+ npth 1.6-1
open-ath9k-htc-firmware 1.4~git20141115.146bff1-1
opkbuild 3.0.0~beta7-1
opkg 0.2.2-1
@@ -87,8 +90,8 @@ packages:
xz 5.1.3alpha-2
zlib 1.2.8+sip1-1
------------------------------------------------------------
- Source packages: 81
- Binary packages: 403
+ Source packages: 84
+ Binary packages: 416
The above list was generated by running the following shell script:
@@ -109,7 +112,7 @@ The above list was generated by running the following shell script:
tblline="${tblline}-"
i=$(($i + 1))
done
- printf "%-${pkgw}s %-${verw}s\n" 'Source Package' 'Upstream Version'
+ printf "%-${pkgw}s %s\n" 'Source Package' 'Upstream Version'
printf '%s\n' "${tblline}"
# Print table
diff --git a/dev/shlibdeps.mdwn b/dev/shlibdeps.mdwn
new file mode 100644
index 0000000..e3003ed
--- /dev/null
+++ b/dev/shlibdeps.mdwn
@@ -0,0 +1,78 @@
+[[!meta title="Automatic Shared Library Dependency Substitution Variables"]]
+
+Background
+==========
+
+Currently, binary packages' control files (`<binpkg>.pkg/control` in source
+packages) must explicitly list library dependencies. Package maintainers can
+manually see ELF files' `DT_NEEDED` entries with tools like **readelf** or
+**ldd** and figure out which binary packages provide each SONAME (usually just
+dropping `.so` from the middle of the SONAME, e.g. `libz.1` provides
+`libz.so.1`). Being a manual process, this method is error-prone: it's an extra
+step that can be forgotten when preparing a new package or updating to a new
+upstream version, it's possible to miss some ELF files in binary packages, etc.
+An automated solution is clearly desirable.
+
+Debian achieves this with a tool called **dpkg-shlibdeps**, which:
+
+ 1. Finds all ELF files in each binary package,
+ 2. Finds all libraries against which each ELF file is linked (i.e.
+ `DT_NEEDED`),
+ 3. Finds dependency libraries on the system (resolving SONAMEs to file names),
+ 4. Looks up the packages that provide each dependency library (with
+ `dpkg -S <lib-file-name>`), and
+ 5. Checks whether each ELF file uses symbols from its library dependencies (and
+ warns of any useless/avoidable dependencies).
+
+ProteanOS should have a similar tool. This document describes how this can be
+implemented.
+
+Implementation
+==============
+
+Changes need to be made in three places in ProteanOS: the Source Package Format
+specification, opkbuild, and opkhelper.
+
+SPF 2.0
+-------
+
+SPF 2.0 needs to be amended to specify `tmp/<binpkg>.substvars` files, like the
+`substvars` file but generated during the build process (while commands from the
+`build` makefile are run and before opkbuild tools complete the package
+build) and specific to each binary package.
+
+opkbuild
+--------
+
+opkbuild needs to read the `tmp/<binpkg>.substvars` files and use them when
+generating binary packages' `control` files.
+
+opkhelper
+---------
+
+opkhelper needs a new tool, which will be called **oh-shlibdeps**, to be run
+after **oh-installfiles**. This new tool will:
+
+ 1. Find all ELF files in each binary package (**oh-strip** already does
+ something similar),
+ 2. Run the C library's **ldd** tool and parse its output (e.g. with
+ `sed -n 's/^\t.* => \(.*\) (.*)$/\1/p;'`) to find the file names of all
+ libraries against which each ELF file is linked (a combination of steps 2
+ and 3 above), and
+ 3. Look up the packages that provide each dependency library (with
+ `opkg search ${filename} | sed 's/ - .*$//;'`).
+
+Detecting useless/avoidable dependencies is considered outside the scope of the
+current proposed design and may be considered in the future.
+
+ProteanOS's `opkhelper-3.0` binary package will need to ensure the existence of
+the **ldd** tool. **ldd** is provided by the `libc-bin` package on the
+`any-any-glibc` architectures (currently all architectures in ProteanOS).
+musl's RTLD (a.k.a. dynamic linker) has **ldd** functionality built-in and
+enabled when executed as `ldd`, so no separate package will be required. So the
+needed dependencies will depend on the architecture, however `opkhelper-3.0` is
+`Architecture: all`, which means it can't have architecture-dependent
+dependencies (which would be solved at build time by opkbuild, not at run time
+by opkg). Therefore, `opkhelper-3.0` will likely have to depend on
+`libc-bin | ldd`, which will work on either `any-any-glibc` or `any-any-musl`
+architectures if the musl library binary package `Provides: ldd`.