5 ms·

Whoever knows how to build systemd should know about this build-time flag

by yadco 6y ago

falcolas 6y ago
I have to picture that systemd has hundreds, if not thousands, of build time flags. Is it reasonable to expect all non-systemd builders to grok every flag? My opinion is that it is not - that pushing it back on the individual distros is a cop out on Red Hat's side. EDIT: 172 distinct build-time options, in today's master. Not all appear to be used as part of the build, since the build script only references 142 of the options set in meson_options.txt.
- ckastner 6y ago
  systemd plays a crucial role on systems that use it. Whoever builds systemd for a distribution should definitely be aware of those flags; if you don’t understand them, then you are not qualified sufficiently to ship systemd for others to use. Edit: Speaking as a package maintainer myself.
  - falcolas 6y ago
    How many packages do you, as a package maintainer, maintain? Can you say with high confidence that you are aware of all of the flags offered by all of those packages, including changes to the defaults between package releases? I expect that package maintainers are human, and put a fair bit of trust in the upstream developers, and will only tinker with build flags for issues which are specific to the distro. I also expect that they will miss changes to defaults, or new flags, or deprecated flags, quite often. I looked at the systemd defaults to see this issue for myself, and the fact that Google's nameservers are in the DNS defaults didn't immediately pop out to me (it's a list of 8 mixed IPv4 and IPv6 addresses).
    - ckastner 6y ago
      > How many packages do you, as a package maintainer, maintain? Can you say with high confidence that you are aware of all of the flags offered by all of those packages, including changes to the defaults between package releases? Absolutely. For a responsible package maintainer, reading changelogs and release notes of new releases is a must. For sensitive software (eg: key system libraries), I usually also look at the full diff between releases. I also run tests with dependent software before uploading my version, lest I break any packages that depend on mine. etc. And this is quite typical of your average distribution package maintainer.
      - falcolas 6y ago
        Fair enough - thank you!
  - deleted 6y ago
    [deleted]
- jschwartzi 6y ago
  Usually if I'm building something from source I read the entire set of configuration flags and take notes on which configurations I might like, which configurations I might want to turn off, and which configurations I don't understand. So yes I would read all the options in the meson_options.txt and decide how I want to configure systemd before beginning the cross-compile. Someone posted the other day that an autotools/automake should canonically be run like this: ./configure make make install But really the best workflow is like this: ./configure --help (read "help" intently) mkdir build_output_dir cd build_output_dir ../configure [huge list of options for the build] make make install I would do the same thing here.

Whoever knows how to build systemd should know about this build-time flag

by yadco 6y ago

Whoever knows how to build systemd should know about this build-time flag

I have to picture that systemd has hundreds, if not thousands, of build time flags. Is it reasonable to expect all non-systemd builders to grok every flag? My opinion is that it is not - that pushing it back on the individual distros is a cop out on Red Hat's side. EDIT: 172 distinct build-time options, in today's master. Not all appear to be used as part of the build, since the build script only references 142 of the options set in meson_options.txt.

ckastner 6y ago
systemd plays a crucial role on systems that use it. Whoever builds systemd for a distribution should definitely be aware of those flags; if you don’t understand them, then you are not qualified sufficiently to ship systemd for others to use. Edit: Speaking as a package maintainer myself.
- falcolas 6y ago
  How many packages do you, as a package maintainer, maintain? Can you say with high confidence that you are aware of all of the flags offered by all of those packages, including changes to the defaults between package releases? I expect that package maintainers are human, and put a fair bit of trust in the upstream developers, and will only tinker with build flags for issues which are specific to the distro. I also expect that they will miss changes to defaults, or new flags, or deprecated flags, quite often. I looked at the systemd defaults to see this issue for myself, and the fact that Google's nameservers are in the DNS defaults didn't immediately pop out to me (it's a list of 8 mixed IPv4 and IPv6 addresses).
  - ckastner 6y ago
    > How many packages do you, as a package maintainer, maintain? Can you say with high confidence that you are aware of all of the flags offered by all of those packages, including changes to the defaults between package releases? Absolutely. For a responsible package maintainer, reading changelogs and release notes of new releases is a must. For sensitive software (eg: key system libraries), I usually also look at the full diff between releases. I also run tests with dependent software before uploading my version, lest I break any packages that depend on mine. etc. And this is quite typical of your average distribution package maintainer.
    - falcolas 6y ago
      Fair enough - thank you!
- deleted 6y ago
  [deleted]
jschwartzi 6y ago
Usually if I'm building something from source I read the entire set of configuration flags and take notes on which configurations I might like, which configurations I might want to turn off, and which configurations I don't understand. So yes I would read all the options in the meson_options.txt and decide how I want to configure systemd before beginning the cross-compile. Someone posted the other day that an autotools/automake should canonically be run like this: ./configure make make install But really the best workflow is like this: ./configure --help (read "help" intently) mkdir build_output_dir cd build_output_dir ../configure [huge list of options for the build] make make install I would do the same thing here.