On Fri, Aug 18, 2017 at 01:21:57PM +0200, Andreas Henriksson wrote:
> I would like to breath some life into this bug report. I've been
> collecting information/brainstorming-ideas about minimal debian
> installation (debootstrap --variant=minbase) on
> https://wiki.debian.org/BusterPriorityRequalification
>
> The e2fsprogs was one of the packages that where questioned if
> it really needs to be Essential: yes / Priority: required.
> It is also one of the largest packages in the minbase set.
There is one thing I can very quickly and easily do to to improve the
minbase set. We can significantly reduce the size of e2fsprogs (by
more half) by simply moving all of its locale files to a new package,
e2fsprogs-l10n. That shrinks installed size of e2fsprogs from 2825k
to 1330k.
> step 1: Switch from Essential: yes to Important: yes
>
> This will not be much of a change in practise. Higher level tools
> like apt etc will still not want to uninstall the package, but
> you can now uninstall it using dpkg without getting the
> 'are you really sure you know what you're doing' question.
> I'd say the most important difference is that according to
> debian-policy (which doesn't know anything about Important: yes)
> the package is now no longer Essential and thus other packages
> are now allowed to add dependencies where needed.
I think you mean "don't know anything about Required: yes" above, but
yes, it seems largely safe to do this. Given that Debian policy
states that packages should not be made "Essential" without a
discussion on debian-devel, I'd probably want to also raise this as a
proposal on debian-devel before changing "Essential: yes" to
"Essential: no".
> step 2: Dowgrade from Priority: required to Priority: important
>
> This means e2fsprogs will still be part of every normal install,
> just not part of 'debootstrap --variant=minbase' (e.g. buildd chroots
> and other specialized systems).
> Pitfalls with this change would be that every package who needs
> something from e2fsprogs (eg. lsattr, chattr) during build phase
> must have a build-dependency on e2fsprogs or they will FTBFS.
> Given we're still early in the Buster development cycle, I would
> personally think this change is pretty safe to do now but depends
> on how much fuzz you're willing to stir up. I'd like to offer
> my help in fixing this (by filing bug reports and doing non-maintainer
> uploads where needed).
It's not just the builders; it will also be the Debian Docker image.
And while it might be fair to say that containers won't need "mount",
it's somewhat more likely that there might be build containers that
will assume the existence of mke2fs.
I'm not sure how to address that, since at least with debian packages
it's a relatively closed universe so we would discover problems as the
reproducible build system tried to rebuild various packages, for
example. But I could imagine so Docker container designed to rebuild
cyanogen or AOSP (for example) that would be assuming e2fsprogs to be
present, and would blow up as a result.
This is one of the reasons why, if the goal is to shrink the size of
minbase shrinking e2fsprogs by removing all of the locale files is
probably the biggest bang for our buck that we can do right away, and
is guaranteed to be 100% safe --- since there won't be any users of
the e2fsprogs locale files except for e2fsprogs itself, and most of
the time they aren't used at all (at least in the English speaking
world :-). (And of course, in build chroots for reproducible-build
reasons.)
By the way, the other program that other packages may be using is
logsave(8) -- the sysvinit and initramfs-tools packages use logsave at
the very least.
> Bonus step: consider chattr/lsattr move to util-linux?
>
> As I understand it, chattr and lsattr used to be ext-specific. Nowadays
> more filesystems seems to have implemented the same interface and thus
> made the tools useful in a broader scope.
Yeah, mumble. I'd have to think about that. We're still adding new
ext4-specific flags to chattr and lsattr, so I'm less enthusiastic
about moving them.
The other libraries/packages that were moved to util-linux where the
uuid and blkid libraries (and associated userspace utilities). Those
were largely no longer changing in any ext4-specific way, so it was a
lot easier to be willing to move it to util-linux. The logsave binary
falls in that category, and so I would have no objections to moving
logsave to util-linux. It's stayed in e2fsprogs mostly out of
inertia.
Regards,
- Ted
