Control: close -1 Ansgar,
On Mon, Jul 25, 2022 at 09:02:09PM +0200, Ansgar wrote: > On Mon, 25 Jul 2022 13:05:02 +0100 Mark Hindley wrote: > > It has been suggested that changing the dependency to > > > > systemd-standalone-tmpfiles | systemd-tmpfiles > > > > would help the packaging system usually find the correct solution and > > reduce the > > number of unexpected surprises users are reporting. > > This change breaks debootstrap as expected: > > +--- > | W: Failure while installing base packages. This will be re-attempted up to > five times. > | W: See /tmp/u/unstable/debootstrap/debootstrap.log for details (possibly > the package > /var/cache/apt/archives/systemd-standalone-tmpfiles_251.3-1_amd64.deb is at > fault) > +--- > > I hope this addresses the question for "evidence and rationale of this > concern" why I say this is problematic. I assume this is the result of running debootstrap with --include systemd-standalone-tmpfiles? > > With this change, on a systemd installation the dependency would already be > > satisfied and therefore noop for APT. For installations without systemd, be > > that > > systems using other inits or in containers, APT would choose the standalone > > implementation. > > You state this as a fact, but it is sadly false. See prior discussions > about systemd-shim which had similar problems and caused various > problems even after removal from the archive (because conffiles). (I'm > too lazy to look this up for another repeat of this argument, after all > it is your claim; I already wasted too much time on the test above.) I am sorry that my lack of experience and familiarity with the internals and history of debootstrap causes such exasperation to you. Perhaps you could find a way to disseminate your considerable knowledge and experience in a more graceful way? Thanks anyway. I withdraw my suggestion. Best wishes. Mark
