On Mon, Oct 02, 2017 at 01:34:47PM +0200, Adam Borowski wrote: > But, we're discussing changes to e2fsprogs behind its maintainer's back. I > believe he reads debian-devel, but, being nowhere like a frequent poster, > apparently doesn't watch new threads immediately as they appear (and this > one started as a response to a 2011 post). > > Ted: could you please chime in? In case you unsubscribed d-devel, it starts > at https://lists.debian.org/debian-devel/2017/09/msg00449.html
Apologies for not responding sooner. Between a crazy travel schedule (kernel summit in Prague, teaching a tutorial at LISA 2017 in San Francisco, and recovering from a killer case of Flu), I just hadn't really gotten to this earlier. 1) If people really want to make e2fsprogs non-essential, I'm not going to object seriously. It's the downgrade of e2fsprogs from Priority: required to Priority: important which where things get super-exciting. 2) I'm at this point I'm not really enthuiastic to move lsattr out of e2fsprogs. We are still adding new features to ext4, some of which will require new flags, and chattr/lsattr et.al. *were* originally designed to be only for ext 2/3/4. Other file systems have decided to use the same ioctl, which is fine, but I've always considered chattr/lsattr to be an ext 2/3/4 utility first, and more generic file system utility second. Moving lsattr out of e2fsprogs to some other package (e.g., util-linux) will make my kernel development much more inconvenient. 3) Lsattr/chattr et.al depend on the e2fsprogs shared libraries, so moving them into a separate binary package isn't going to save as much space as you would like. So it's not at all clear the complexity is worth it. 4) If the real goal is reduce the size of minbase, there is a much more effective thing we can do first, or at least, in parallel. And that is to move the l10n files to a separate foo-l10n package. The last time I did this analysis was with Debian Jessie, but I don't think the numbers have changed that much. Of the 201 MB i386 minbase chroot, 33MB, or over 16% can be found in /usr/local/locale. The breakdown (using Debian Jessie numbers) are: Package Savings Cummulative (kB) Savings (kB) Percentage coreutils 8052 8052 24.91 dpkg 4620 12672 39.20 bash 3744 16416 50.78 gnupg 3424 19840 61.37 e2fsprogs 1776 21616 66.86 tar 1680 23296 72.06 shadow 1632 24928 77.11 apt 1528 26456 81.84 libapt-pkg4.12 1052 27508 85.09 Linux-PAM 796 28304 87.55 findutils 756 29060 89.89 grep 636 29696 91.86 diffutils 620 30316 93.78 debconf 596 30912 95.62 adduser 444 31356 96.99 sed 428 31784 98.32 libgpg-error 388 32172 99.52 systemd 84 32256 99.78 acl 72 32328 100.00 In Debian Stretch, I've already done this separation for e2fsprogs, so the installed size of e2fsprogs is only 1309kB. And so I've already made harvested way more than half of the savings of getting rid of e2fsprogs from the minbase set by the simple expedient of moving the /usr/share/locale files to e2fsprogs-l10n. Simply splitting coreutils into coreutils and coreutils-l10n would reduce minbase by a factor of *six* over getting rid of e2fsprogs from minbase. Does this mean trying to get to Essential: no for e2fsprogs is a bad thing? No, but if your goal is reduce the size of minbase for Debian, I just want to point out that there is **much** lower hanging fruit that folks might want to consider harvesting first. Cheers, - Ted P.S. In case it isn't obvious, the reason why it's interesting to shrink the size of minbase is that it makes Debian much lighter-weight for Docker --- you don't need e2fsck or mke2fs in most docker containers based on Docker; neither do you need the translations into Turkish, German, Spanish, Chinese, etc., for e2fsprogs, coreutils, dpkg, etc., for most Docker containers. When I asked the question *why* is it worth it to spend the effort to reduce the size of Essential: yes, I was told it was it was a prerequisite of reducing the set of packages where Priority is "required", and *that* was because it allowed for a reduction of the minbase set, which in turn is intersting for reducing the size of Docker images. If there are other reasons why people want to make e2fsprogs no longer essential: yes, it's good to have those out on the table, since it may be that there are other things we can do first, or in parallel, that might be *far* more effective towards the real end goal that people have.