Re: Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2022-10-26 at 13:21 +0100, Luca Boccassi wrote:
> > On Wed, 2022-10-26 at 11:39 +0100, Richard Purdie wrote:
> > > > On Tue, 2022-09-20 at 19:18 +0000, Luca Boccassi wrote:
> > > > > > Following this thread started back in April:
> > > > > > 
> > > > > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html
> > > > > > 
> > > > > > As far as we understand there are no distributions running or
> > > > > > optionally supporting systemd that have not either completed, or at
> > > > > > least started, the transition to merged-usr systems.
> > > > 
> > > > For the record and to be really clear, Yocto Project has systemd
> > > > support but also supports arbitrary filesystem layout. We have not
> > > > planned or agreed to drop that filesystem layout configuration/support.
> > > > It is actively used today by our user base today, perfectly fine.
> > > > 
> > > > The statement above is therefore misleading as there are distributions
> > > > out there which have not even agreed to the change and are not planning
> > > > a transition.
> > > > 
> > > > I was asked by Luca to test the "usr-merge" config with systemd and it
> > > > failed in our CI, which is sadly what I suspected would happen. It
> > > > takes time in itself to even queue up these kinds of tests and process
> > > > the results. I did this several months ago and have seen no interest or
> > > > help in fixing the result.
> > > > 
> > > > This change from systemd effectively mandates we change our
> > > > configuration to match what systemd dictates and only support that. I
> > > > don't like what that represents and don't consider it a positive
> > > > development.
> > 
> > Also for the record, Yocto has had (configurable) support for merged-
> > usr for a long time, and we've been using it in production at $work for
> > 3+ years without any issue. Also, Yocto supports many many
> > configuration options, and they are definitely not all compatible with
> > each other - there are conflicts and dependencies, as it is natural

Sadly systemd is probably one of our bigger sources of
incompatibilities (musl would be a significant example). We did go to
some lengths to adapt around some of systemd's other requirements,
mostly successfully as people don't seem to be hitting them.

> > , so
> > adding a systemd -> usrmerge dependency seems technically workable and
> > conceptually reasonable, and it's not that different from other
> > requirements and dependencies that are already there. You don't have to
> > switch !systemd builds, if you don't want to, even if it would be a
> > good idea of course. You still have one year (on top of the ~10 years
> > since this has been a done thing) to fix/skip/drop those faulty unit
> > tests.

Alternatively, I could move systemd support into it's own layer and
drop it from core given it appears to be incompatible with an
increasing portion of our configurations. A new maintainer could then
take on these issues and sort it out and I could stop caring about it.

> > I mean, the fact that the Yocto-supported usrmerge option is not
> > compatible with Yocto-internal unit tests is hardly our fault, no?

Not your fault, no. People use the project very widely for $work
purposes and they get significant benefit from our core unit tests, it
is likely why you've managed to use things "without any issue". Some
kind of help and support from people using it in such cases might be 
helpful and ensure their use cases are being tested and maintained. 

You're probably a lot better placed to help us figure out how to test
systemd is working optimally for example. Our test cases are less about
unit testing and more about whether the integration all works together
or not as the upstream projects tend to focus more on the unit tests.
Where we can, we do try and run any unit tests available as well
though.

> > From my point of view it really sounds like you have too many options and
> > not enough QA resources to cover all configurable combinations
> > effectively. It almost seems like dropping some of those variations,
> > say those which provide no technical value for example, might be a good
> > idea to focus QA resources and improve overall quality ;-) Of course
> > it's your distro, so you are perfectly entitled to do as you see fit.

Not really, you're going to stop us :).

> > Sorry to disappoint, but we will certainly not delay yet again because
> > of fixable unit test issues in one downstream distro. At this point
> > merged-usr is table stakes and the basis for so many things to build on
> > top, that it is just not reasonable anymore for us to support not
> > having it in 2023, more than 10 years after it was introduced.

My point was that the original statement was incorrect and I don't like
things being presented differently to the reality.

I was unaware of this being an issue until a few months ago.

Systemd has made it clear in the past that it isn't interested in Yocto
Project and it's use cases or users and that we should just take what
we're given and do what we're told. In that sense you're not
disappointing me, you're doing exactly what I've come to expect. I'd
just like it on record that this is the case which it now is.

There is a bit of an irony that I actually agree with much that systemd
has done and/or is doing, just less so on how.

Cheers,

Richard





[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux