All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Norbert Lange <nolange79@gmail.com>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] package/systemd: bump to version 251.3
Date: Tue, 19 Jul 2022 18:21:38 +0200	[thread overview]
Message-ID: <20220719162138.GL2249625@scaer> (raw)
In-Reply-To: <20220719130449.334694-1-nolange79@gmail.com>

Norbert, All,

On 2022-07-19 15:04 +0200, Norbert Lange spake thusly:
> Add config option for the new sysupdate feature.

Honestly, with a package so complex and critical like systemd, I would
prefer that new features not be added during the bump, but as followup
patches. The bump should add a force-disable of new features (when
known), or just leave them as auto-detected or upstream-decided
defaults.

> Remove upstreamed patch.
> 
> Update options, manually setdefault options, remove option

Sorry, I don't immediately see what "manually setdefault" means...
Is there a missing space, and this should be "manually set default" ?
Or is "setdefault" and actual systemd concept?

(genuinely asking)

> not available anymore.
> 
> Set default-user-shell based on wether a couple packages
> are enabled.
> 
> Set default-locale to C, this seems the only safe default,

How does that play with BR2_ENABLE_LOCALE_WHITELIST? I think that we
would want to use the first word of BR2_ENABLE_LOCALE_WHITELIST is it is
set, falling back to just 'C' otherwise.

Furthermore, that is not a novelty with v251; v250 already had that
option, so that should be a separate, preliminary patch.

> users can override this in `/etc/locale.conf`.

> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
[--SNIP--]
> diff --git a/package/systemd/systemd.hash b/package/systemd/systemd.hash
> index 3572b25965..838ed13fd5 100644
> --- a/package/systemd/systemd.hash
> +++ b/package/systemd/systemd.hash
> @@ -1,5 +1,5 @@
>  # sha256 locally computed
> -sha256  d2bda9d225da11dc9ff48b48e59fc36798d3e66902ed400a9f78fa370c596864  systemd-250.4.tar.gz
> +sha256  11c9c3fcc13d689615dd2ea79161d1b992087cf1e2a23856d7d7ade0efbddc54  systemd-251.3.tar.gz
>  sha256  ab15fd526bd8dd18a9e77ebc139656bf4d33e97fc7238cd11bf60e2b9b8666c6  LICENSE.GPL2
>  sha256  dc626520dcd53a22f727af3ee42c770e56c97a64fe3adb063799d8ab032fe551  LICENSE.LGPL2.1
>  sha256  e5a8645ad94aab24e312dd0c6be2aa54236eb9374480b1b14ea5c61598874fd5  LICENSES/BSD-2-Clause.txt
> @@ -11,4 +11,4 @@ sha256  790ac93fb2859097bdda4cf08b5a4feb5e479d0cb2c74f403248241bc3e7c216  LICENS
>  sha256  b85dcd3e453d05982552c52b5fc9e0bdd6d23c6f8e844b984a88af32570b0cc0  LICENSES/MIT.txt
>  sha256  2a98749f6bec00dfaed86fa9c1edea871aaae4f11ee4d100b671aaf4ce353a73  LICENSES/murmurhash2-public-domain.txt
>  sha256  1a7adaa2c86cedfd6c7f5c0c7c72fd6d3e02cd0c9593f21fdb53c89bb2b130ec  LICENSES/OFL-1.1.txt
> -sha256  11801e931f252252a16eac8299465510d0a82c36bfd9ac8aea9b202b76d2f82b  LICENSES/README.md
> +sha256  177ff657698bc940f9888b7f69e5d734b0933c2859ea264fde8de1700cec40dd  LICENSES/README.md

What has changed in that license file? How does it impact (or not) the
licensing info we carry?

We have hashes for license files, so that we know they licensing terms
change when a package is updated. Silently changing the hash kind of
defeats the purpose for those hashes...

> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 46a4e8de2c..b6fffc553f 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
[--SNIP--]
> @@ -472,6 +474,20 @@ else
>  SYSTEMD_CONF_OPTS += -Dsysext=false
>  endif
>  
> +ifeq ($(BR2_PACKAGE_SYSTEMD_SYSUPDATE),y)
> +SYSTEMD_CONF_OPTS += -Dsysupdate=true
> +else
> +SYSTEMD_CONF_OPTS += -Dsysupdate=false
> +endif
> +
> +ifeq ($(BR2_PACKAGE_BASH),y)
> +SYSTEMD_CONF_OPTS += -Ddefault-user-shell=/bin/bash
> +else ifeq ($(BR2_PACKAGE_ZSH),y)
> +SYSTEMD_CONF_OPTS += -Ddefault-user-shell=/bin/zsh
> +else
> +SYSTEMD_CONF_OPTS += -Ddefault-user-shell=/bin/sh
> +endif

We already have BR2_SYSTEM_BIN_SH which defines what /bin/sh is, and so
I think we should use exactly /bin/sh as the default shell:

    ifneq ($(BR2_SYSTEM_BIN_SH_NONE),y)
    SYSTEMD_CONF_OPTS += -Ddefault-user-shell=/bin/sh
    endif

If there is not default shell for the system, then there is none for
users as well. Systemd-defined users that want a specific shell will
have to explicitly request it: if they have a requirement for a specific
shell, they can't rely on whatever the default is, so usng /bin/sh is
exactly what we want.

If BR2_SYSTEM_BIN_SH is empty, it is perfectly possible that there is no
shell available at all (no standalone shell, no shell in busybox), so we
don't want to set any default either.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2022-07-19 16:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19 13:04 [Buildroot] [PATCH 1/1] package/systemd: bump to version 251.3 Norbert Lange
2022-07-19 16:21 ` Yann E. MORIN [this message]
2022-07-19 21:56   ` James Hilliard
2022-07-20 14:51     ` Norbert Lange
2022-07-20 16:52       ` James Hilliard
2022-07-21 14:40         ` Norbert Lange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220719162138.GL2249625@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=nolange79@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.