Hi, On Sun, 01 Oct 2017 00:45:39 +0200, Helmut Grohne wrote:
> In 2011 Steve Langasek proposed dropping Essential: yes from e2fsprogs. > > On Sat, Mar 26, 2011 at 11:47:08AM -0700, Steve Langasek wrote: >> Currently the e2fsprogs package is marked Essential: yes in the >> archive. Is this a historical holdover? I believe e2fsprogs used to >> ship /sbin/fsck, but since 2009 (i.e., util-linux (>= 2.15~rc1-1), >> which e2fsprogs has a pre-depends on), this has been provided by >> util-linux instead. >> >> The remaining programs provided by e2fsprogs are all specific to the >> ext* family of filesystems, so I don't think meet the definition of >> Essential any longer - their presence is certainly important if you >> have an ext[234] filesystem, but while this is the default, you can >> have systems that don't use ext* at all, which makes e2fsprogs no more >> essential in nature than the other per-filesystem fsck tools. >> >> Now that the transition to util-linux is done in a stable release, is >> it time for us to drop the Essential: yes flag from e2fsprogs? This >> will benefit those targetting embedded systems that don't use ext, >> where the package will be dead weight; the risk of any packages >> assuming availability of these e2fs-specific interfaces without a >> dependency is quite low; and we're at the right point in the cycle to >> make changes to the Essential set, where we have time to deal with any >> unexpected fallout. > > Since then we have fully transitioned to systemd and init has become > non-essential. The issue around pulling e2fsprogs into essential via > logsave has thus solved itself. > > I think we should revisit this proposal now that it becomes practical. Thanks for resuming this work. > > To get us going, I have come up with a plan: > > 1) Analyze which packages would need dependencies on e2fsprogs. >From what I gather in the files you attached, these packages are flagged for preinst/postrm and thus may be problematic: 1. e2fsck-static (appears to be false positive) 2. lilo (uses kernel preinst hook) 3. blktrace (appears false positive) I don't know how the kernel hook works, is it problematic? > 2) File a bug against lintian to stop complaining about e2fsprogs > dependencies. +1 > 3) MBF those packages that need an e2fsprogs dependency. > 4) Drop Essential: yes from e2fsprogs. As Adam mentioned, we will need to wait one release to drop the Essential: yes bit :( . Alternatively, e2fsck would have to gain Breaks: against all unfixed rdeps. For such a core package I think this might be problematic for upgrades, but I haven't tested. > So I thought, "how hard can it be?" All we need to do is grep the > archive for those tools and add those dependencies. So I unpacked sid > main amd64 and grepped[1] each and every file (potentially decompressing > gzip) for those e2fsprogs. The results[2] are 5666 occurrences in 1250 > binary packages. From there, I started looking[3] into the actual uses > and filtered common non-uses such as documentation, debug symbols, > kernel images, locales and other stuff. I manually checked the remaining > packages and thus went down[4] to 318 occurrences in 133 binary > packages. Thus I arrive at the final dd-list (attached) for an MBF. We > can now say that our package lists will increase by less than 1.5kb > uncompressed if we make e2fsprogs non-essential. In comparison, the > average binary package weighs 767 bytes. I believe that the method used > is mostly free from false negatives (by looking for bare program names > in each and every file) and has a manageable number of false positives. > > I think we can check off the analysis part. How about proceeding with > the lintian bug and the MBF now? Did I miss anything? I think this is OK. Thanks again for the work, and I think we should proceed. The earlier, the better! -- Saludos, Felipe Sateler