[Buildroot] [PATCH v7 3/8] core: implement per-package SDK and target
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Tue Nov 5 16:38:30 UTC 2019
Hello Jan,
Yes, some feedback on an almost year old comment!
On Tue, 08 Jan 2019 19:02:56 +0100
Jan Kundrát <jan.kundrat at cesnet.cz> wrote:
> I gave this series (the ppsh-v7-work merged into master, actually, with a
> revert of 51395b14ed1a23858eef5d7f2bcf3a03cca6dfb3). The only immediate
> breakage I see so far on my config (ARM, systemd, glibc, linaro toolchain)
> is related to systemd-networkd and its /etc/resolv.conf symlink handling,
> but I am afraid that I see a bigger problem.
>
> The basic skeleton defines a symlink (it's in
> system/skeleton/etc/resolv.conf) pointing to ../tmp/resolv.conf . This is
> overwritten in package/systemd/systemd.mk through
> SYSTEMD_INSTALL_RESOLVCONF_HOOK, and indeed it results in a correct symlink
> in the systemd's per-package target dir:
>
> per-package/systemd/target/etc/resolv.conf ->
> ../run/systemd/resolve/resolv.conf
>
> The problem is that at the rsync time, packages are processed in
> alphabetical order. If the very last package to be rsynced (in my case,
> this is zlib) does not transitively depend on systemd, then rsync will
> update the /etc/resolv.conf symlink back to one obtained from the default
> skeleton.
Indeed. Clearly, we have identified since quite a while that the
per-package directory mechanism only works if all packages install
distinct set of files, unless they have a dependency relationship.
> I think that this is -- potentially -- also a problem for any package "P2"
> which calls `ln -sf` from its *_INSTALL_TARGET_HOOKS to overwrite stuff
> which belongs to another package "P1". If any other package "P3" depends on
> "P1" and not on "P2", *and* if P3's name sorts after P2, then the P1's
> symlink gets preserved via P3.
>
> This will not necessary be fixed by changing to do the rsync in a
> dependency order because "P3" can still be rsynced after "P2".
>
> What is the cleanest fix here? Should this symlink overriding go to
> *_TARGET_FINALIZE_HOOKS? If the `ln -sf` was just in TARGET_FINALIZE_HOOKS,
> that would mean that the corresponding per-package/*/target would *not*
> contain these fixes which would be quite confusing, IMHO... OTOH, two hooks
> for overwriting would be ugly.
For the case of resolv.conf, I think solving it through a
TARGET_FINALIZE_HOOKS is probably the most appropriate option for now.
We'll have to see later on if we have other cases like this, and if
there is a pattern that allows us to invent some useful bit of
additional infrastructure.
Or we could:
(1) Move the /etc/resolv.conf symlink from system/skeleton/ to
package/skeleton-init-sysv/skeleton/etc.
(2) Tweak the systemd.mk so that it always creates resolv.conf, either
pointing to ../run/systemd/resolve/resolv.conf when resolved is
enabled, or to /tmp/resolv.conf otherwise.
This would avoid the overwriting entirely.
What do you think ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
More information about the buildroot
mailing list