On Sun, 29 Nov 2020 15:12:55 +0200 Joonas Kylmälä <joonas.kylm...@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.
pgpR1I7HjrYxW.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list Replicant@osuosl.org https://lists.osuosl.org/mailman/listinfo/replicant