Bug#696123: partman-base: need progress wrapper for non-libparted-based filesystem operations
Package: partman-base
Version: 162
Severity: wishlist
parted 3.x removes most of the ped_file_system_* entry points that
required extensive copies of file system code in libparted, with the
exception of some limited support for HFS+ and FAT resizing (see its
NEWS file for more details; facilities such as file system probing are
still available). d-i still uses these for important functions. In
most cases we fall back to external utilities, but if there are any
remaining places where we don't then we'll need to fix those.
However, simply falling back to external utilities is not a
functionally-equivalent option right now, because in general we have no
support for handling progress information from those utilities. Most of
them have some kind of progress interface, usually requiring some
special option and designed for human consumption rather than machine
parsing.
Rather than the Sisyphean task of giving all the appropriate utilities
machine-parseable progress interface, I instead suggest that we study
the current progress interfaces and try to identify some common factors
that can be parsed heuristically (e.g. solid bar of characters;
"\-/|"-style spinner; percentage output), and write a wrapper utility
that can translate some of the common ones into debconf progress output.
I think this ought to be a single program in partman-base, since there
are only so many ways people have invented for console progress
interfaces and we don't want to keep reinventing the wheel. We can then
use that to wrap various mkfs, resize, etc. utilities, and in the
process fix some ancient bugs about lack of progress feedback in various
operations since some cases haven't actually used libparted's file
system support for a while.
The relevant parted_server commands to grep for in various partman-*
modules for ideas on the kinds of utilities that need to be wrapped are:
CREATE_FILE_SYSTEM
CHECK_FILE_SYSTEM
RESIZE_PARTITION
(Theoretically also COPY_PARTITION but we have no fallback for that; we
may have to either desupport this or reimplement it by hand somehow.)
I looked at doing this once but unfortunately I seem to have lost the
source code for my attempt; I'd only really made a start at it anyway.
I'm filing this bug as a memory aid, and because people keep asking me
what's happening with packaging of parted 3.x and I want to have
something reasonably coherent to point them to.
--
Colin Watson [cjwatson@debian.org]
Reply to: