On Wed, 13 Jul 2022 at 00:30, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Tue, 12 Jul 2022 at 22:55, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > > > On Tue, 2022-07-12 at 18:16 +0100, Luca Boccassi wrote: > > > On Mon, 11 Jul 2022 at 23:06, Richard Purdie > > > <richard.pur...@linuxfoundation.org> wrote: > > > > > > > > On Mon, 2022-07-11 at 21:29 +0100, Luca Bocassi wrote: > > > > > From: Luca Boccassi <luca.bocca...@microsoft.com> > > > > > > > > > > Support for unmerged-usr is deprecated upstream, taints the system > > > > > and will be > > > > > removed in the near future. > > > > > Enforce building merged-usr images when using systemd. > > > > > > > > > > Signed-off-by: Luca Boccassi <luca.bocca...@microsoft.com> > > > > > --- > > > > > We intend to deprecate unmerged-usr at some point, and we are doing > > > > > the > > > > > rounds ensuring distros are moving along so that there are no > > > > > surprises > > > > > when the time comes. > > > > > > > > > > See: > > > > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html > > > > > > > > > > meta/recipes-core/systemd/systemd.inc | 5 +++++ > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > diff --git a/meta/recipes-core/systemd/systemd.inc > > > > > b/meta/recipes-core/systemd/systemd.inc > > > > > index b8dbe2263a..f9e109bba4 100644 > > > > > --- a/meta/recipes-core/systemd/systemd.inc > > > > > +++ b/meta/recipes-core/systemd/systemd.inc > > > > > @@ -21,3 +21,8 @@ SRC_URI = > > > > > "git://github.com/systemd/systemd-stable.git;protocol=https;branch=${S > > > > > " > > > > > > > > > > S = "${WORKDIR}/git" > > > > > + > > > > > +# unmerged-usr support is deprecated upstream, taints the system and > > > > > will be > > > > > +# removed in the near future. Fail the build if it is not enabled. > > > > > +inherit features_check > > > > > +REQUIRED_DISTRO_FEATURES = "usrmerge" > > > > > > > > Given none of our systemd testing on the autobuilder is done under > > > > usrmerge and we've never mentioned this requirement to any of our > > > > userbase before, this is going to come as a bit of a surprise to > > > > people. The above change will break the autobuilder as things stand :(. > > > > > > Yes I was expecting there would be these kind of issues, the purpose > > > of sending this was mainly to find out about them. > > > So where are these configurations stored? How can we get them updated? > > > > The configuration is yocto-autobuilder-helper but the best place to > > start is probably the poky-altcfg distro config. > > > > Once we change that we'll have to run through the testing, see how much > > breaks and then find someone to try and fix any issues if/as needed. > > There is a lot of work just in pulling things together for testing and > > triaging the result and I'm depressed it will probably end up on my > > plate when I personally disagree with the decision. > > We've been running this configuration internally for ~3 years in our > Yocto downstream, never seen any issue, not even at the beginning, it > just worked. > Nowadays most major distros have switched over, Gentoo's the other one > left but it's planned for this year. > Any issues in upstream softwares should have been fixed years ago when > Fedora started the process. > So hopefully it shouldn't be too bad? > > > I was asked earlier today if we should just make the systemd include > > files force usrmerge on. The challenge is that OE/YP give users choice > > to configure their system how they wish, we don't just force > > configurations upon them. Or only real option is therefore to throw > > errors and have them decide what to do (which basically amounts to > > submitting to the upstream decision). > > > > > Also is a deprecation notification needed? How is it handled usually? > > > > Do we have time for such a notification or are we in the situation > > where we just throw errors to the user and let them agree to the > > usrmerge change? The timescale is unclear but if the systems are > > already throwing deprecation warnings at runtime, this isn't a good > > experience for our users. > > It's not urgent. But the build-time warning has been in place for a > couple of years now, you should have already seen it. > The runtime is a taint flag in 'systemctl status', and was introduced > in the most recent release. > There is no timeline as of now for dropping legacy compat code and > configuration, as the runtime taint was just added. > Certainly won't be this year. I've been doing the rounds ensuring > everyone who hasn't switched already is aware with plenty of time to > spare.
FYI, we now have a tentative timeline: first release of H2 2023 will drop support for split-usr and unmerged-usr: https://github.com/systemd/systemd/blob/v252-rc2/NEWS#L14 Kind regards, Luca Boccassi
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171977): https://lists.openembedded.org/g/openembedded-core/message/171977 Mute This Topic: https://lists.openembedded.org/mt/92319509/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
