Hi Michael, Michael Biebl <bi...@debian.org> ezt írta (időpont: 2021. júl. 9., P, 22:42): > > Hi Guillem, > > thanks for your feedback > > Am 09.07.21 um 13:46 schrieb Guillem Jover: > > If the private library has no backwards or forward compatibility (due > > to the SONAME used) the time window where the library does not match > > the expectations of the stuff linked to it might indeed be too big. > > The libsystemd-shared library is considered an implementation detail and > indeed has no guaranteed backwards or forward compatibility. > The soname is bumped when the first rc1 release is made (e.g v249-rc1 → > libsystemd-shared-249.so) and there might even be incompatible changes > between the rc1 and the final release. > > > But the reported bug is just a symptom of a bigger issue. This problem > > already exists for any of the other binary packages built against this > > private shared library, there's a time-window where they will not work > > if the installation gets interrupted or fails, compared with public > > shared libraries. > > This observation is correct I'd say. Currently we have the following > split-off binary packages which ship binaries that link against > libsystemd-shared: > > systemd-container (4 binaries in $PATH, 7 services, 11 total) > systemd-coredump (1 binary in $PATH, 1 service, 2 total) > systemd-journal-remote (3 services, 3 total) > systemd-timesyncd (1 service, 1 total) > > (I'll exclude systemd-tests, as this is a special case) > > The main difference here, is that none of those binaries is really > critical for the runtime of the system. > An unbootable system though is one of the worst things that can happen. > Which is why I'm really reluctant to split off libsystemd-shared from > systemd and hopefully also explains why in general I'm not super keen on > chopping up src:systemd unnecessarily. > > > This implies to me the correct solution is a name-versioned package, > > even though that seems cumbersome given our current archive handling > > practices this is IMO the only correct solution. > > A name-versioned package would certainly be better then an unversioned > libsystemd-shared package. It still would make PID 1 a bit more brittle > though (see e.g. my comment regard rc releases). > It would also need patching of the build system, to override the rpath, > which would have to be multi-arch aware. > > $ find . -name meson.build | xargs grep rpath | wc -l > 123 > > This would be a significant patch with a lot of ongoing churn and > maintenance effort. I'm not sure if I'm willing or even able to do that.
IMO what Guillem recommends, i.e. the name-versioned libsystemd package with versioned shared library name is still the cleanest and so far the only reasonably reliable solution. IMO going through NEW in every few months could be an acceptable cost especially since I was quite happy with the pace at which NEW is processed recently. I don't maintain systemd in Ubuntu anymore, but if I were, I'd be happy to accept this increased maintenance burden for the sake of having a clean solution for the Multi-Arch problem. If release candidates will be uploaded only to experimental then the incompatible changes won't cause problems. Even if RC-s are uploaded to unstable and a rarely occurring incompatible change takes place then the library package name can be bumped again. After we discussed this topic on #debian devel on 2020-05-05 I even started implementing the solution but did not finish it because it was not an important problem from Ubuntu's POV. I think the rpath usage search counted a lot of hits which don't have to be changed and maybe upstream would be willing to accept the patch. Cheers, Balint
