On Wed, 2022-10-26 at 14:40 +0100, Richard Purdie wrote: > 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.
Our requirements are very clearly and openly stated. If you want to run on an unsupported libc (rather than fixing that libc to provide the needed features, which would benefit everybody) it is up to you of course, but you can hardly blame this project. > > > , 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. It's your distro, so again up to you. > > > 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. The point is that the usrmerge option in Yocto is not related in any way to systemd, it's provided by the distro itself for various purposesfor and has been for years, just like those tests that fail when it is enabled. The fact that those don't work together is not in any way related to systemd, it's an internal problem of QA resources in Yocto. > 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. We have both unit tests and integration tests, but integrating them in your platform is up to you. The unit tests are fairly easy, but the integration tests are not. They are supported and ran (upstream) on Fedora/CentOS/Arch/Debian/Ubuntu because people from each of those projects spend considerable amounts of time and resources to maintain them. It would in principle be feasible to run them on Yocto too, but it's someone from the Yocto project that needs step up and volunteer do the work on an ongoing basis - it is not going to be us, there's just not the bandwidth nor the expertise. Then it would become easy to also adopt them downstream, that's how other distributions do it. > > > 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. That's not quite how it works. This is a members-led project. The project doesn't have to be interested in Yocto, it's the other way around, Yocto maintainers need to show they are interested and actively participate in the project, send high quality bug reports and pull requests, and eventually become part of the upstream maintainers group. This is how all other distributions contribute and ensure it works well for their use cases. It is a perfectly valid choice to sit on the sidelines, but then you can't complain about being sidelined. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
