On Saturday 14 July 2007 20:15, Robert Millan wrote:
> > - we already have parted-udeb, which I expect _does_ support GPT
>
> In my use case, the person who was installing had to call me because he
> had to edit a GPT disk and didn't know how to handle parted. With my
> proposed solution, I would have told him to "apt-install gnu-fdisk";
> but instead I had to do all the partitioning myself.
Aren't you confusing apt-install and anna-install here?
To be honest, I do not think that "some individual being unable to handle
parted" is much of an argument. Especially as even using parted is only
an last-ditch alternative to using partman. Partman is the partitioning
tool of choice in the installer, and nothing else.
We have other limitations in D-I that could be added by adding a whole
range of tools (either by default or optional).
Some basic rules for D-I development are: keep it simple and lean; no
duplication; no frills. That translates to: if we already have parted to
cover your use case, we don't want nor need gnu-*fdisk.
Now, maybe a case _could_ be made to drop the current fdisk udeb and
switch to gnu-fdisk instead. However, that would mean that some serious
comparison of both utils would need to be presented on the list.
This would of course mean that for some architectures it _would_ be loaded
by default, so such an analysis would have to include size and memory
differences.
However, the fact that the package is relatively new (not even included in
Etch) and its dependency on libparted IMO make a switch unlikely, at
least in the short term.
> > - the new udebs conflict with the fdisk/cfdisk udebs, but udpkg does
> > not support Conflicts: (design decision)
>
> We can rename the binaries and drop the Conflicts. If we rename fdisk
> to fdisk-gnu rather than gnu-fdisk, it'll even make shell expansion
> work.
That would work, but we first need to determine that we actually want the
gnu-*fdisk udebs.
> > - the gnu-cfdisk udeb depends on ncurses, which is not acceptable
>
> In that case we could provide gnu-fdisk only.
OK.
> But why is ncurses not acceptable? If it's a size issue, note that our
> typical use case has at least one >2 TiB disk, so we should expect it
> to be able to spare a few hundred kiBs of memory for ncurses (when user
> wants to, not by default!)
There are various reasons against:
- the use-case presented here is WAY to weak to warrant supporting a new
library for D-I
- it would add a udeb to yet another library package, which would mean an
added maintenance burden on its maintainer, and a quite significant added
burden on the D-I release manager and on the Debian release managers
(added complexity for migrations - especially complex transitions - to
testing)
My conclusion remains that we currently do not need/want either of the
gnu-*disk udebs.
Note that this policy is not something that I have invented. Joey has also
always been quite strict about adding new udebs, or even new commands
(such as ping) to D-I.
Cheers,
FJP
Note: I appreciate all these creative technical solutions for debian-cd
and accepting new udebs. Yes, improvements are undoubtedly possible, but
I prefer to work based on the toolset that is actually available, not
some imaginary features that nobody is likely to implement (assuming that
they would be accepted by the relevant maintainers).
D-I and Debian release management are already a huge job. More udebs add
considerably to the workload for both and thus have to be considered
carefully.
More udebs = more risk of random regressions = more risk of migration
blockers = more risk of release delays = more stress and headaches.