[Buildroot] [PATCH v3 2/7] pkg-autotools: optimistically set runstatedir
Yann E. MORIN
yann.morin.1998 at free.fr
Sat Sep 10 12:35:38 UTC 2022
Norbert, All,
On 2022-02-22 11:22 +0100, Norbert Lange spake thusly:
> since Autotools 2.70 there is an option to set the
> runstatedir. To support configure scripts using older version,
> the variable is set directly instead of using the --runstatedir
> argument.
>
> Signed-off-by: Norbert Lange <nolange79 at gmail.com>
> ---
> package/pkg-autotools.mk | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
> index 717ff81593..b6224b349d 100644
> --- a/package/pkg-autotools.mk
> +++ b/package/pkg-autotools.mk
> @@ -187,6 +187,7 @@ define $(2)_CONFIGURE_CMDS
> --exec-prefix=/usr \
> --sysconfdir=/etc \
> --localstatedir=/var \
> + runstatedir=/run \
We have unfortunately had to revert this change as well as all the
various hacke we tried to fix it, for various reasons (list below
serving as a memo for the futur):
1. --runstatedir only appeared in autotools 2.69b, and we still have
packages that were autoconf-ed with previous versions, and thus
do not support the option;
So we tried with passing it as a variable assignment, but...
2. passing runstatedir=/path as a variable assignment on the command
line actually breaks packages with very old autotools versions, like
2.13, which get confused as they believe this is specifying the
host;
So we got back to an option, but only if we could grep it in the
configure script; yet...
3. packages that do recognise --runstatedir in their top-level
configure script, may still break with configure scripts in
sub-directories, written with older autoconf vrsions, so back to
square one.
Given that we are nearing the release, given that FHS 3.15 does
acknowledge that /var/run can continue to exist for backward
compatibility, and that it suggests individual programs (not whole
systems!) to only use one or the other, we should just continue to
support /var/run (if at least for binary-only cruft that may still be
lying around and need /var/run anyway).
As a consequence, not having a generic solution to pass --runstatedir
(or an equivalent) is not a blocker, and is not a regression either.
Sure, having it would be better, but we can't make it work reasonably
well for now.
So, here is a brain-dmup of some thoughts about that (stil just thinking
about autotools here):
- packages that actually want to access runstatedir will have a way to
specify it, be it the option or the variable assignment, or even
something else;
- packages that have neither the option nor the variable, would most
probably not need to access runstatedir at all.
As a consequence, what are the odds that a package needs runstatedir?
Are they legion, or are they few? If they are relatively few, then we
can just add the applicable solution (option or variable) on a
per-package basis.
And I think this is most probably the simplest and most efficient
solution, as we can't have a generic one.
Unless we can come with a much clever solution...
Speaking of cleverness: Peter suggested checking for --runstatedir
recursively in all configure scripts, and only pass it if they all
suport it.
However, I think this might be incorrect: the top-level configure script
could support it, and the package needs it, but sub-configures may not
support it (or there is a file named configure in a sub-dir, which is
not an actual configure script (or is not needed), in which case we
would miss the opportunity for the generic solution, and we'd be back on
a per-package _CONF_OPTS...
So, I'm still thinking the per-package _CONF_OPTS is way better
overall...
Untill we can get a better solution, or all upstream packages have been
fixed and bumped in Buildroot... :-]
Thanks for the initial patch! We tried, it did not work, we reverted.
Regards,
Yann E. MORIN.
> --program-prefix="" \
> --disable-gtk-doc \
> --disable-gtk-doc-html \
> --
> 2.34.1
>
> _______________________________________________
> buildroot mailing list
> buildroot at buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| 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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list