dev/pkg/opkg/static: New page

1 files changed, 70 insertions, 0 deletions

diff --git a/dev/pkg/opkg/static.mdwn b/dev/pkg/opkg/static.mdwn
new file mode 100644
index 0000000..cb623b2
--- /dev/null
+++ b/dev/pkg/opkg/static.mdwn
@@ -0,0 +1,70 @@
+[[!meta title="Static libopkg"]]
+
+[[←_Back_to_Opkg in ProteanOS|dev/pkg/opkg]]
+
+Background
+==========
+
+ProteanOS currently dynamically links the `opkg` executable against a
+`libopkg.so.1` shared object and provides the latter in a separate `libopkg.1`
+binary package for use by any other applications that might also use libopkg.
+In ProteanOS, only the `opkg` package depends on `libopkg.1`.  Additionally,
+there don't seem to be any other actively maintained applications, at least none
+released publicly, that use libopkg.
+
+With only one dependent executable, a library is more space efficient when
+statically linked into that executable than when built as a shared object and
+dynamically linked into the executable.  The reason is that the library's
+symbols can be stripped if statically linked into the executable.  The symbols
+in a shared object, on the other hand, are needed at run time to resolve uses of
+those symbols in the executable to their addresses in the shared object.
+
+Therefore, on a ProteanOS system that uses opkg but doesn't need libopkg for any
+other applications, some space can be saved by statically linking libopkg into
+the `opkg` executable.  There are a couple of ways this can be done.
+
+Options
+=======
+
+Option 1
+--------
+
+One option is to simply statically link libopkg into the `opkg` executable in
+the `opkg` binary package and drop the `libopkg.1` and `libopkg.1-dev` binary
+packages.   This is the simplest option and saves the most space overall in the
+package archive, however it doesn't allow any future libopkg-using applications
+to be added to ProteanOS.
+
+Option 2
+--------
+
+Another option is to leave the `libopkg.1`, `libopkg.1-dev`, and `opkg` binary
+packages as they are and introduce a new `opkg-static` package with an `opkg`
+executable statically linked with `libopkg.so.1`.  The `opkg` binary package
+would continue to depend on `libopkg.1`, while `opkg-static` would not.  This
+allows platforms *without* other libopkg-using applications to use opkg without
+libopkg's symbols and allows platforms *with* other libopkg-using applications
+to share libopkg between multiple executables.  This however comes at the
+expense of increased package archive size.
+
+An alternative to the naming of the `opkg` and `opkg-static` binary package
+names is to use `opkg-dynamic` and `opkg`, respectively.
+
+Option 3
+--------
+
+A compromise between options 1 and 2 is to leave the `libopkg.1` and
+`libopkg.1-dev` binary packages as they are and statically link the `opkg`
+executable in the `opkg` package with libopkg, without building an `opkg`
+executable that dynamically links against libopkg.  This means duplicated code
+and some increase in file system usage on any platforms that may someday include
+some other libopkg-using application in the future.  But it also minimizes file
+system usage on platforms where opkg is the only user of libopkg, like option 1,
+and balances package archive size between options 1 and 2.
+
+Conclusion
+==========
+
+We'll probably go with option 1 at first.  If we add any other libopkg-using
+applications in the future, we can switch to option 2 with the `opkg-dynamic`
+and `opkg` binary package naming scheme, for backwards compatibility.