Bug#887266: initscripts should depend on e2fsprogs explicitly
Maybe it was only me it escaped, but please note that initscripts already Recommends e2fsprogs. Apparently this used to be a Depends but was downgraded to Recommends (in 2009), according to the following debian/changelog entry: * Reduce initscripts dependency on e2fsprogs to recomments and drop the versioned relation, as the version needed (1.32+1.33-WIP-2003.04.14-1) was included in a version before oldstable (Closes: #379340). The rationale is in https://bugs.debian.org/379340 (but please note that some things have changed since this discussion. For example the 'fsck' wrapper is shipped by util-linux these days). Maybe that should be considered good enough to just close this bug report? WDYT? Regards, Andreas Henriksson
Bug#887266: initscripts should depend on e2fsprogs explicitly
On Mon, Jan 15, 2018 at 02:35:01AM +0100, Adam Borowski wrote: > This is an interesting case. Indeed. > Small containers, systems and chroots that need an init really want to use > sysvinit (thus initscripts) instead of systemd, as it's drastically smaller, > both in terms of memory use and disk size. Thus, they're what needs removal > of e2fsprogs the most -- ie, adding the dependency wouldn't be the right > thing to do. Correct. > As you have researched relationship between minimal install packages, you > likely know more than me. Thus, could you advise? I'm sorry. I tend to ignore sysvinit nowadays. My approach here would be to add the dependency as that is no regression: initscripts currently (implicitly) depends on e2fsprogs and it keeps doing so. Then as a secondary step, I'd leave it to people to actually remove the dependency by refactoring either initscripts or e2fsprogs. Of course if both systemd and sysvinit end up pulling e2fsprogs, we'll not win much. But we know precisely where to look then. Helmut
Bug#887266: initscripts should depend on e2fsprogs explicitly
On Mon, Jan 15, 2018 at 02:35:01AM +0100, Adam Borowski wrote: > Small containers, systems and chroots that need an init really want to use > sysvinit (thus initscripts) [...] No init or 'dumb-init' are other choices people are advocating for that use-case. I don't think using sysvinit in containers should be considered the normal usecase for it, so I'd argue that adding the dependency for now until someone volunteers to further refactor things (as helmut already suggested, but see also below) [...] > Yes, these scripts to use logsave. If I read codesearch's output right, > there are only two packages that use it: > * initramfs-tools > * initscripts [...] > self-contained .c file that can be tossed around and shipped in any arch:any > package. [...] The discussion about moving logsave around is in #619785 . Please consider also #501481 first though as that would probably make the entire point moot from sysvinit side! (See also #524007 related to logsave usage in sysvinit/initscripts.) Regards, Andreas Henriksson
