diff options
Diffstat (limited to 'dev')
| -rw-r--r-- | dev/archive/signing.mdwn | 16 | ||||
| -rw-r--r-- | dev/pkg/needed.mdwn | 14 | ||||
| -rw-r--r-- | dev/ports/hardware.mdwn | 18 | ||||
| -rw-r--r-- | dev/releases/1/packages.mdwn | 11 | ||||
| -rw-r--r-- | dev/shlibdeps.mdwn | 78 |
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`. |