[Replicant] [libsamsung-ipc] [PATCH 3/3] Add guix.scm

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Tue Dec 1 11:08:31 UTC 2020


On Sun, 29 Nov 2020 15:12:55 +0200
Joonas Kylmälä <joonas.kylmala at iki.fi> wrote:

> I have one concern: if we introduce these packaging files and then the
> distro wants to modify them because we did it suboptimally [...]
While technically this builds some packages, the produced packages are
not intended to be used by users as such, and certainly not by
Guix.

Instead guix.scm files (which is merely a convention) are typically used
by various projects to do testing: with it you can build your project
(here libsamsung-ipc) in various ways (which packages typically don't
do) and with various dependencies if needed.

For instance if you work on a python software, you might want to add
tests to your software and create as many packages variations as
possible in your guix.scm to build (and tests) your packages with
python2 and python3 and openssl and gnutls, and so on. 

Since you can also run tests while building packages (make check), this
is very useful.

This kind of testing configuration is not suited at all for
distributions but is very well adapted for maintaining software.

In my case I intend to use it to test if the patches I'm about to merge
introduce any regression with the compilation.

As for adding libsamsung-ipc in general purpose distros, it's probably
best to at least wait until the API change is finished: changes like
"[...] pass the ipc_client struct" break the API/ABI, and for
consistency we probably want to make sure that we did that change on
all the functions that are being exported first.

In addition, libsamsung-ipc is not very interesting to package in
general purpose distributions like Guix yet:
- nv_data-imei can only read the IMEI and cannot write it so far.
- nv_data-md5 is of limited use without information that enables to
  change useful things in the .nv_data.bin
- The modem and device drivers in libsamsung-ipc are currently made for
  vendor kernels APIs and the Linux modem driver is not in upstream
  Linux and general purpose distros typically use upstream Linux or
  Linux-libre.
- Even if might be possible to use a generic distro with a vendor
  kernel, many things will probably break as the vendor kernels become
  old at some point, and tend to break the API and ABI. SHR did adapt a
  big part of the userspace to cope with that, and general purpose
  distros don't do that. We even had code to handle the Android power
  management in freesmartphone.org for that. We build device specific
  versions of packages if needed, etc.

So to be useful for general purpose distributions we either would need
more information on the nv_data.bin or have an upstream modem driver
(with the associated part in libsamsung-ipc) and probably an easy way
for users to boot an upstream kernel on any of the supported devices
(for instance by having u-boot in the BOOT or RECOVERY partition as
this is redistributable).

When that happens, I could for instance package libsamsung-ipc in
Guix and in that case Guix will not have to modify or use our guix.scm
in any way.

It would rather be the opposite: Guix would be more like an upstream
for the package definition and we could inherit from it if we want or
keep a separate fork if needed.

Guix also accepts patches and I've currently a setup that is able to
test patches, and I've already sent them some very minor patches for
Android related stuff.

So even if I've currently a very limited understanding of lisp and the
guile variant of it, I'll most likely be able to fix things in the
upstream Guix package of libsamsung-ipc if me or someone else adds
libsamsung-ipc in Guix.

As for security issues, Guix is a rolling release distribution so
fixing any security issues could be done by making a new release of
libsamsung-ipc and updating the package definition upstream.

When other distributions that have fix releases start using
libsmsung-ipc if we have security issues, we'll probably have to
backport the security fixes, and here too, the packages definition
won't be a big issue. It's more the backporting of the patches that
could potentially be an issue. When all that happen, it would probably
mean that libsamsung-ipc became more useful for general purpose
distributions and so we might have more contributors (like the
package maintainers) helping with that kind of things.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20201201/03627dc9/attachment.asc>


More information about the Replicant mailing list