Zbigniew Jędrzejewski-Szmek wrote:
> Meson outclasses CMake in functionality,
LOL, how so? Everything in Meson is hardcoded, you have very little
flexibility (but still enough to plant a backdoor if that is what you want,
because you can just invoke a shell script or any other external command).
CMake is completely extensible with a complete programming language (it is
Turing-complete if and only if you use recursive functions; if you avoid
FUNCTION or at least recursive ones, then it is guaranteed to always
terminate and still usually expressive enough, but Turing-completeness
through recursion is there if you really need it).
> clarity, and brevity.
That is very much in the eye of the beholder, and it also depends on whether
you use modern CMake or legacy constructs that are often overly verbose.
Meson does not have so much legacy stuff simply because 1. it is much newer
(which also means it is less mature) and 2. it cares less about backwards
compatibility (which is not a good thing, backwards compatibility is
essential if you want to avoid upstreams bundling old copies of build
tools).
> I doesn't make sense to consider switching to CMake at this point.
CMake being what the whole Qt and KDE community uses nowadays (even Qt
itself switched to it with Qt 6), it very much makes sense to switch to
CMake now more than ever.
The main reason Meson is a thing at all (and not just one person's little-
known project as it initially was) is that GNOME did not want to use the
same build tool KDE was already using (even though they had the exact same
issues with autotools).
> I don't think a separate library would be particularly useful.
> sd_notify() as used by sshd just writes a static string to a unix
> socket. This can be implemented in ~10 lines of C, including error
> handling.
Copy&paste is exactly what we do not want here. (It can easily be done
wrong, either accidentally or deliberately, introducing security issues, and
any security issue discovered in the copied&pasted code has to be fixed in
all the copies.) If daemons are likely to need only one function
(sd_notify), then a library containing only that one function is exactly
what is needed, no matter how small it is.
> If that is the _only_ thing needed from libsystemd, then open-coding it
> is a good option. I guess it'd make sense for systemd to provide a header
> file that provides a reference documentation as an inline function.
That is an option which is better than copy&paste, but it still means that
all users will need to be rebuilt if a bug in that header file is fixed (as
for a static library, but unlike a shared library).
> One thing which is happening, mostly for unrelated reasons, it that
> systemd code is being changed to use dlopen() for various libraries which
> are usually not needed at runtime. The primary motivation for this is to
> omit such libraries from the initrd. But this also helps with overlinking.
>
> In systemd git main, libsystemd is only linked to libc, libcap,
> and libgcrypt + libgpg-error. A pull request to convert that that last
> pair to dlopen is under review.
That helps somewhat (it would have prevented this backdoor from working),
but it also makes things even less transparent: How do we know whether some
random sd_foobarify() function or some random foobard linked against
libsystemd will (always or ever (and when?)) end up dlopening liblzma or
not?
Distribution packagers tend to dislike dlopen due to the hidden dependencies
it introduces.
Kevin Kofler
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
