[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#430023: please add gnu-fdisk-udeb and gnu-cfdisk-udeb



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.

Attachment: pgpfFRsWAxsKS.pgp
Description: PGP signature


Reply to: